AWS had a packed expo hall, about 9,000 people, and a slate of new feature and service announcements for the San Francisco Summit. Here are some key takeaways.
Hi, I’m Forrest Brazeal at Trek10, and this is ‘Think FaaS’, where we learn about the world of serverless computing in less time than it takes to run a Lambda function. So put five minutes on the clock - it’s time to ‘Think FaaS’.
I spent part of last week in San Francisco attending the AWS Summit. It tells you something about the state of the AWS ecosystem that they had about 9,000 people in house, a packed expo hall, and a whole slate of new feature and service announcements for what is not even their biggest event of the year. Quite a few of the announcements related directly to serverless applications, so let’s break down some key takeaways from San Francisco.
First, a fun announcement from Serverless general manager Tim Wagner: SQS is coming as a Lambda event source! It’s not actually available for us to use yet, but his team showed a demo of the functionality and it looks pretty far along, so I’d expect to see it in the console soon. This is good news if you’ve been writing scheduled Lambdas that poll a queue - it’s just one more step toward making your architecture fully event-based.
Second, there’s a new way to manage secrets for your Lambda functions (and lots of other things too).
Lambda secret management has been a source of shame for many of us. I’ll echo Tim Wagner and remind you: do not put secrets in Lambda environment variables. I know it’s tempting. I’ve been guilty of it myself. But it’s a dangerous security practice, and you should be putting your database credentials somewhere that’s encrypted, that supports rotation, and all that good stuff.
The good news is that AWS has just released something called the AWS Secrets Manager, so it’s easier than ever to maintain good hygiene for your secrets. This is a KMS-encrypted place for secrets that supports fine-grained IAM access control. Some of the AWS RDS services have native integrations with Secrets Manager and will rotate credentials for you automatically. What’s really cool is that you can hotwire Lambda functions into the service to create custom rotations for other secrets as well. It’s a big step up from the SSM parameter store, and now we have less excuse than ever to put anything in a Lambda environment variable that we wouldn’t commit to source control.
My one concern about the Secrets Manager is that it’s a bit pricy - forty cents per secret per month, which could add up fast in an enterprise environment. But it’s a lot cheaper than a data breach caused by careless key management, that’s for sure. I definitely will be checking this service out.
A broader security-related theme I took away from the summit is that AWS is finally getting serious about cross-account security and management tooling. Secrets Manager is designed from the ground up to work with multiple accounts. The new AWS Firewall Manager, also announced last week, provides much of its value by integrating with AWS Organizations. Even the updates to AWS Config rules were focused on creating a single multi-account, multi-region dashboard. AWS customers are realizing that accounts are not the ultimate security boundary, and the services are catching up. And when you rely on services rather than servers, this transition makes a lot more sense.
In addition to the announcements, I spent a fair amount of time on the expo floor catching up with various tooling vendors and others in the serverless space. I had a nice chat with Austen Collins of the Serverless Framework. His team is working on some very ambitious stuff, and I recommend keeping a close eye on what they release over the next few weeks.
It was also good to connect with Eric Hammond, one of the original AWS Community Heroes, who did a talk in the developer lounge about his experiences building a deployment pipeline for a fully serverless application. He’s using the AWS Code services - CodeCommit, CodePipeline, CodeBuild - to push out code changes to his static website. Having worked with this kind of setup quite a bit myself, I can say that it’s a bit more challenging than it appears. For example, Eric actually can’t use a Lambda function to generate his static site pages because there’s not enough disk space or working memory on Lambda, so he has to use a CodeBuild job. It’s a good reminder that Lambda is not a silver bullet for all ad hoc compute tasks, so don’t forget about services like CodeBuild and Fargate.
Finally, on Thursday evening I did a fireside chat on serverless with Tim Wagner at Silicon Valley Bank. We had a good group of people, mostly CTOs and engineering directors, who were very interested in making serverless work for them. Tim obviously has fantastic insights on serverless, so I hope we’ll be able to release a recording or a transcript of that session at some point. There were a lot of questions about cold starts on Lambda, and Tim underscored some recent AWS efforts in that area. Interestingly, AWS has recently started moving warm Lambda containers between physical machines so customers don’t experience an unexpected surge of cold starts caused by underlying hardware maintenance. I thought that was fascinating, and it’s just a tiny glimpse into the type of engineering challenges that go into making Functions as a Service a mature compute option.
That’ll do it from me. If you’re looking for more serverless updates, you can stay up to date by following Trek10 on Twitter @Trek10Inc, I’m there as well @forrestbrazeal, and we’ll see you on the next episode of Think Faas.
