Because something wasn't in place to make it work. There are millions of examples where the second mover won, often because the first mover was too early, or the tech wasn't there to make it work, or the market didn't understand the value, etc.
In this case I imagine there are three massive benefits that you'd have over being the first mover:
- AWS is more mature and therefore moving slower, so it's easier to keep up.
- AI is useful for building 80% working code, so there's a lot less to do to keep up.
- There's a lot of devs looking for ways to move off Localstack due to the price change, which gives you (potentially) a pool of willing volunteers to contribute to an OSS alternative.
You can also learn from Localstack's open source version about what's needed, what works, what doesn't work, etc.
If I’m getting into esoteric features or some “big” features that don’t make sense locally, then I just spin up a real dev account of aws, so I know I’m getting the real experience.
The problem is that everybody needs different "core" features
> > compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind)
For instance, I don't care about any of those features at all. But I would care a lot about EC2, RDS, and ElastiCache Redis
Or I am doing something so specific, that a local emulation of the aws api isn’t ever going to be good enough, so there’s not a lot of point in trying. For example, writing code that handles automatically spinning up RDS instances from an RDS snapshot — a local emulation of that process is going to be so far off from what would actually happen no matter what they do.
I'm using all of the above in LocalStack today. Frankly, I don't believe this is as "impossible" a task as several in this thread are insinuating. It's the type of rote work you can delegate to AI to build these days, as observed in this OP.
Building a test suite to validate the state-transient mocks in question against the real deal is not difficult. Only annoyingly expensive (in time and money) if run often, which is exactly the problem they're solving.
you should tell that to the LLM that writes your website:
> MiniStack is your free, MIT-licensed drop-in replacement.
is it a drop-in replacement, or not?
You fake half the error modes or your test rig drfits from prod fast.
Literally as I write this the AI code review said "suspended-bucket current-version selection is still wrong when the numbered version and the newer null version land in the same millisecond." - thats the level of detail you have to deal with.
I do think there's potential to semi-automatically create a compatible suite of services, but it'll require some very talented use of LLMs and some novel testing approaches. Not something I want to sign up for.
I evaluated Floci, but that has the typical issues you'd expected with freshly minted vibe code.
I mean, if we can use "virtual-AWS", it would dramatically lower entry-barrier for devs/companies who are scared of "tales of huge aws bills" and such