How LocalStack Won Me Over on Mocking AWS Locally
Longtime followers of my various nonsense may recall that, in years past, I was very much opposed to the idea of local development for cloud workloads — particularly Serverless projects. “You can’t develop on a plane with remote dev, but honestly, how often is that a problem?” was one of my points, as an example.
Then, toward the end of 2021, I stopped talking about mocking cloud services locally (but obviously didn’t stop mocking cloud services in general). This was the result of a single conversation with the founders of LocalStack, a company based on a project that came out of Atlassian.
Why local development for AWS makes sense
The premise of LocalStack is simply to emulate AWS APIs and their responses for local development. It’s an idea that always struck me as a little bit goofy for two primary reasons.
First, AWS has a lot of services, each with their own sprawling APIs. That’s one hell of a lot of surface area to cover. It’d be borderline impossible to cover the majority of the services along with their various behaviors.
Second, developing against an ersatz implementation of AWS services inherently means you’re reducing the fidelity of your development environment as compared to production. Down this path lies a whole mess of trouble of the “works on my machine” variety.
The LocalStack team’s answer to these issues was rather insightful and, with the benefit of hindsight, blindingly obvious:
Imagine a large enterprise that onboards a few thousand developers a year. Some percentage of them will need to learn how AWS works. How do you build effective guardrails that let them develop against the platform without introducing a whole bunch of friction? Or without running the risk of cost overruns and data leakage?
Then, look at the large customer environments you encounter. How many services are they using on a daily basis that are meaningful workload components for their applications? And for those services, how much of the API surface are they really working with?
I started that conversation expecting to affirm my relatively low opinion of LocalStack’s approach. I ended it asking to invest in the company. I’ve been a (very) small investor in LocalStack ever since.
Let’s build something locally
With the launch of LocalStack 2.0, now seems as good a time as any to talk about what my experience with it has been like.
In a cloud security equivalent of a memento mori, I have a website that actively checks whether IAM has failed open globally. You can see it for yourself at HasIAMFailedOpenYet.com. It’s pretty cloud-native; it’s an API Gateway that’s connected to a Lambda function. When invoked, it checks whether it has permissions to access something that it very explicitly does not. Should that call ever succeed, it will display a radically different message than it currently does. All of this is deployed via the CDK, and it works well.
I have to make one change to my codebase to get this to work, since we’re all barely functional piles of technical debt. I’ve hardcoded the Zone ID for the Route 53 zone responsible for the domain into my code; generating a local Route 53 zone with the same name and swapping out the Zone ID is a prerequisite here.
Then, a simple cdklocal bootstrap; cdklocal deploy takes about 90 seconds to complete. It generates a CloudFormation template, uploads it to the local endpoint, and provisions the 35 resources I defined via the CDK. That includes S3 buckets; API Gateway integrations; Lambda functions, which in turn execute in Docker containers locally; and, most useful for latency purposes, fake ACM certificates that’ve been DNS validated. LocalStack’s CloudFront emulation doesn’t include the several minutes of waiting around for it to update globally as a blocking condition; it just updates the thing and carries on.
When it completes, I can visit the site locally and see exactly what you see when you visit HasIAMFailedOpenYet.com (though admittedly I do have to click through a TLS certificate error first). I’m able to rapidly iterate on the site, redeploy it, and never incur a penny of AWS charges.
Message from a reformed skeptic
Local development for cloud services is not, it turns out, nearly as silly as I once thought. LocalStack can lower costs when it comes to safely training developers, building efficient workloads, and, sure, standing up ridiculous websites. The breadth of AWS API coverage LocalStack has managed to deliver is rather breathtaking (and I don’t just say that as an investor). Its customer list reads like a who’s who of enterprises that take their business seriously.
While I wouldn’t use LocalStack for everything, I absolutely will be using it for a subset of things that I don’t feel like paying big money for AWS development. And since it works on any arbitrary laptop, you can emulate AWS on a plane — which is exactly where I’ve written this post.
