Notes from re:Invent 2022: a serverless/devops recap

This week was my first time attending re:Invent, and it was as intense as I had imagined! With 60k people flying into Vegas for the conference and dozens of events happening every single hour of the day, picking and choosing what to spend time on was a challenge. I got a great overview of the new (and some existing) serverless and devops tools, though, and met some awesome new people, which was my primary goal. I'll write more detailed articles about select sessions next week, but here were my favorites, with links to YouTube so you can watch them too!

Building containers for AWS (CON325)

https://www.youtube.com/watch?v=S7JwFFZ-7_Q

If you build Docker containers locally on macOS, this was a talk for you. Phil Estes and Jesse Butler did an entertaining job of presenting a new open-source alternative to Docker Desktop on macOS called Finch.

Check out the talk for details, but my main takeaways were:

1. Finch is a macOS native client for container development.
2. Finch uses the same interface you're all familiar with for building containers (i.e. finch build -t [name:tag] . instead of docker build -t [name:tag] .)
3. Use the --secret parameter to pass in your secrets to the container on build, and then use --mount-type=secret when you run. Don't put secrets in layers and delete them later! They're still there, embedded in the previous layer.
4. Use multistage builds to make your containers MUCH smaller.

Deep dive into Amazon Neptune Serverless (DAT322)

https://www.youtube.com/watch?v=WwuAfTpL7ww

Not a lot of developers use graph databases, but since basically everything in the real world can be represented as a graph, they're incredibly useful! And now you can run a Neptune graph database without allocating servers (kind of). Takeaways:

1. You can't scale down to zero, the minimum your cluster can go is to 2.5 NCUs. This is about $290/month at $0.1608/hr per NCU, which is pretty pricey for an absolute minimum serverless setup. They're working on lowering minimums.
2. Can only scale up to about the size of a r6g.8xlarge
3. Is not yet supported by CloudFormation (I am constantly surprised by how poorly AWS supports CloudFormation).

Practical experience with a serverless-first strategy at Capital One (SVS311)

This one hasn't been uploaded to YouTube yet, but it was one of my favorites of the conference. They set it up as a back and forth between a very senior engineer at Capital One and an AWS architect, both explaining their own recommended best practices for Lambdas at scale (Capital One uses a LOT of Lambdas). Takeaways:

1. Use Lambda init (cold start) to cache secrets for subsequent calls to the same warm Lambda
2. Lambda init gives you a whole CPU (no fractional throttling) no matter what your allocated Lambda size is. This means you can do "Lambda power tuning" to optimize for cost/performance
3. If you get errors in your init phase, this will result in stuck Provisioned Concurrency. AWS won't retry, you'll need to release a new version

How AWS Application Composer helps you and your team build great apps (SVS211)

Again, no upload yet for this one. AWS Application composer is basically a visual yaml editor for CloudFormation templates.

I'm looking forward to using this to visualize existing architectures already built in CloudFormation, but right now the tool is pretty limited (it's still in Preview). Takeaways:

1. The service is very slick for quickly and visually compiling new resources into a yaml
2. It doesn't hook directly into CloudFormation state, you have to upload the actual yaml file if you want to see an existing architecture
3. There are a bunch of services that it doesn't support out of the box (it doesn't error when loading such a yaml, it just grays out the unsupported services).
4. Basically it's just a yaml visualizer/editor for now. The service is promising though!

Governance Guardrails across your multi-account environment (COM312)

A great dev talk by Paushali Kundu about how Thomson Reuters manages compliance enforcement and monitoring across their 300+ AWS accounts.

I learned about CloudFormation Hooks for the first time, which can enforce rules on CloudFormation stacks.

Accelerating workloads using parallelism with AWS Step Functions and Lambda (API205)

Yet another one with no uploaded video. I was initially skeptical about map/reduce with Step Functions and Lambda, only because there are already so many great tools to do massively parallel data processing. I was pleasantly surprised though!

If you have millions of CSVs (or whatever) on S3 that you want to process in parallel, they've made it SO EASY to do so. Basically all you have to do is use a visual editor on the AWS console to make a mapping of S3 objects->Lambda function mapper, and then plug in a final reducer lambda, and you're done. They did a live demo where they processed 550k csv files on S3 in about 2 minutes, it was awesome. Takeaways:

1. If you don't want to set up your own cluster to do your map/reduce calculations, absolutely use Step Functions
2. Concurrency limits can be tuned so you don't overwhelm externally-called services that have API limits
3. You can easily specify how many files to batch in a single Lambda by the number of items OR a number of kilobytes
4. You can set a number of items that can fail before the whole thing fails, OR you can set a percentage of map invocations that can fail
5. You can send the compiled results from the mappers directly to S3

That's it for now, I have to catch my flight! I'll be writing more about re:Invent next week.