Did you ever stop to think how much time you’re wasting on slow Docker builds for your serverless functions? Apparently, AWS did. Or at least, someone finally whispered it loudly enough in the right ear.
The AWS Serverless Application Model (SAM) CLI, a tool many of us grudgingly accept as the lesser of several deployment evils, has just received a couple of significant upgrades. We’re talking about BuildKit support for container image builds and native WebSocket API resources. Two things that, frankly, should have been there yesterday.
This isn’t just a cosmetic polish. These are tangible improvements that chip away at the friction inherent in cloud-native development. Let’s break down why you should even care.
The BuildKit Bottleneck, Solved?
For anyone building Lambda functions using container images—and more people are doing this these days, believe it or not—the old sam build process was a relic. It was kicking the can down the road using an outdated Docker SDK. No parallel build stages. No efficient layer caching. Just… slow.
SAM CLI has always been good at taking the grunt work out of serverless deployments. You define your functions and APIs in a template, and SAM handles the CloudFormation, the packaging, the deployment. It works.
But “it works” isn’t exactly a rallying cry for innovation. The legacy builder meant you were missing out on all the good stuff BuildKit has offered for years. Cross-architecture builds? Forget it. Multi-stage Dockerfile optimizations? A pipe dream. It was like showing up to a knife fight with a spork.
Now, with SAM CLI v1.156.0 and the --use-buildkit flag, it’s a different story. You tell SAM to use BuildKit, and it shells out to the Docker CLI or Finch CLI. Suddenly, you get parallelism. You get smarter caching that actually understands dependencies. You get stages that are skipped if they don’t matter. And that improved cross-architecture support for those Graviton2 instances? Finally within reach.
This isn’t just about speed. It’s about better, more reliable builds. Especially if your Dockerfiles are more than a handful of lines or you’re dealing with private package registries during the build. The --secret flag integration, which arrived in v1.159.0, is particularly welcome. It means you can inject credentials for private repos without baking them into your image layers. Smart. Like it should be.
Is This Really ‘Serverless’ Anymore?
Here’s where my journalistic skepticism kicks in. SAM is ostensibly for serverless applications. Yet, here we are, talking about Docker daemons and CLIs. It’s a reminder that for all the abstraction layers, the underlying container machinery is still very much alive and kicking. This BuildKit integration, while welcome for image-based Lambdas, further blurs the line between pure serverless functions and more traditional containerized workloads. Is it a sign of things to come? Or just a pragmatic concession to developer reality?
WebSocket APIs: Finally Off the Shelf
Then there’s the WebSocket API support. For years, if you wanted to build a real-time application with AWS API Gateway’s WebSocket capabilities using SAM, you were out of luck. You either had to drop down to raw CloudFormation—a delightful experience for all involved, I’m sure—or just avoid SAM for that piece of your infrastructure.
This meant writing out the AWS::ApiGatewayV2::Api, the routes ($connect, $disconnect, sendMessage), the integrations, the deployment stages. It was verbose, repetitive, and error-prone. Now, there’s a native resource type. You define your WebSocket API in your SAM template, specify your routes and their Lambda integrations, and SAM handles the rest.
It’s hard to overstate how much this simplifies things for developers. It’s not a paradigm shift, but it’s a significant reduction in boilerplate. It means more developers will likely embrace SAM for full-stack serverless applications that require real-time communication, rather than building it piecemeal or with other tools.
The Caveats
Of course, nothing is a magic bullet. BuildKit support is opt-in. You have to explicitly pass the --use-buildkit flag. Your CI/CD pipeline needs the Docker or Finch CLI installed, not just the daemon. And if you’re still clinging to ZIP-based Lambda functions (bless your heart), this update is irrelevant. For WebSocket APIs, it’s good, but it’s still API Gateway. It’s not like they’ve reinvented the wheel, just put it on the SAM car.
But let’s face it. These are overdue, sensible additions. They make a popular developer tool just a little bit better, a little bit faster, and a whole lot less frustrating. For Open Source Beat, that’s a win worth reporting.
Is This Just More Cloud Hype?
While these updates are practical, it’s worth remembering that AWS often rolls out features incrementally. BuildKit support is a smart move to keep pace with industry standards in container building. The WebSocket API resource is simply catching up to existing AWS capabilities. It’s less about a revolutionary leap and more about refining the existing developer experience. The real “hype” would be if they managed to simplify the underlying complexities of API Gateway itself, which they haven’t done here.
🧬 Related Insights
- Read more: Debian Package Integrity: Forget Guessing, Use
debsums - Read more: Project Glasswing: Big Tech’s $100M Bet to AI-Arm Open Source Defenders
Frequently Asked Questions
What exactly is BuildKit?
BuildKit is a new, faster, and more efficient builder toolkit for Docker images, offering features like parallel build stages, better caching, and improved cross-architecture support.
Do I have to use BuildKit for my Lambda builds now?
No, BuildKit support is opt-in. You need to explicitly pass the --use-buildkit flag to sam build for it to take effect.
Will this help my existing ZIP-based Lambda functions?
No, this update is specifically for Lambda functions packaged as container images (PackageType: Image).
How do I define a WebSocket API in SAM?
SAM now includes a native resource type for AWS::ApiGatewayV2::Api, allowing you to define WebSocket APIs, routes, and integrations directly within your SAM template.
