One issue is that local emulation runs into some big political rocks as soon as it gets good. To start with, the emulator is good enough and covers a tiny surface of what people want, eg k8s and s3. Resistance here is about customers experiencing issues caused by gaps in fidelity vs the real environment and subsequent pain for the emulator product team. ok, fine.

But then you get customers who take your emulator and use it in places where AWS cant go, eg, airgapped environments. They start asking for more serious features. But wait! another team in the hyperscaler was already trying to solve this, for far more than zero dollars. Azure Stack. Azure Local. AWS Snowball. Now there are VPs shooting at you because you are, in their view, cannibalizing their revenue.

You might try to avoid this war by emphasizing the dev sandbox aspect, selling to developers only and making sure that you only talk about APIs and stuff. Problem is, the API surface is 90% of why the cloud is useful (the other ten percent being the assertion that you don't have to think about it, which is an increasingly untrue proposition, as the reams of SREs will tell you). So now you have an emulator for the most valuable part of Cloud, in the hands of people who know how to use it and are strongly incentivized and capable of making it better, all running locally. It's a very small step to making that commercial and wiping huge chunks of revenue out, as your VP will tell you as they sign your pink slip.

Talking to devs, the most common thing I hear re emulation is a desire to be able to let rip on any service and not fear a giant bill. Since all clouds have budget tools I wonder why this isnt possible today? Maybe theres a weakness in the planning tools rather thanthe post-use budgeting ones?

AWS don't want that support nightmare.

Great to see Localstack offset a bit thanks to ... AI driven shift left infrastructure tooling? This is a great trend.

You should build your software around abstractions and interfaces which are portable enough to work locally and in AWS or any other cloud and not just AWS specific APIs.

Localstack does have IAM emulation as part of the paid product. I'm intrigued to see how well this does at the same thing.

When you're running hundreds of integration test suites per day in CI pipelines, the free tier is irrelevant. You need fast, deterministic, isolated environments that spin up and tear down in seconds, not real AWS calls that introduce network latency, eventual consistency flakiness, rate limits, and costs that compound with every merge request.

It'd be great to just use AWS but in practice it doesn't happen. Even if billing doesn't, limits + no notion of namespacing will hit you very quickly in CI. It's also not practical to give every dev AWS account, I did it with 200 people it was OK but always caused management pain. Free tier also don't cover organizations.

> they MUST learn that there are no hard spend limits, and the only way to actually learn it, is to be bitten by it as early as possible

This is a bizarre take. "The best way to learn fire safety is to get burned." You can understand AWS billing without treating surprise charges as a rite of passage.

Security for dev accounts is not a big deal, just give each developer an individual account and set up billing alerts.

>how do we know it won't be sent elsewhere?how do we know it won't be sent elsewhere?

I the past open source meant that you trusted in theory that someone else would notice and report these things. These days though just load up your LLM of choice and ask it to do a security audit. There are some unreliable ways to cheat this and they aren't magical, but it would be pretty hard to subvert this kind of audit.

So I’m shocked cloud providers haven’t just done this themselves, given how feasible it is with the right harness

Mentions CLAUDE.md and didn't even bother deleting it.

So by the time you’re ready to push to staging you should be past the point of wanting to emulate AWS and instead pushing to UAT/test/staging (whatever your naming convention) AWS accounts.

Ideally you would have multiple non-production environments in AWS and if your teams are well staffed then your dedicated Cloud Platform / DevOps team should be locking these non-prod environments from developers in the same way as they do to production too.

Bonus points if you can spin up ephemeral environments automatically for feature branches via CI/CD. But that’s often impractical / not pragmatic for your average cloud-based project.

But you can’t have every dev tweaking staging at the same time as they work. How can you debug things when the ground is shifting beneath you?

Ideally every dev has their own AWS account to play with, but that can be cost prohibitive.

A good middle ground is where 95% of work is done locally using emulators and staging is used for the remaining 5%.

One of the first things I do when building a new component is create a docker compose environment for it.

I recently discussed this with an adjacent org that didn't use a local environment at all outside of junit mocks for unit testing, and their deployment pipelines take over 45m per commit. Ridiculous.

However, there is a dedicated Dockerfile for creating a native image (Java words for "binary") that shouldn't require a JVM. I haven't tested running the binary myself so it's possible there are dependencies I'm not aware of, but I'm pretty sure you can just grab the binary out of the container image and run there locally if you want to.

It'll produce a Linux image of course, if you're on macOS or Windows you'd have to create a native image for those platforms manually.