MiniStack (replacement for LocalStack)(ministack.org) |
MiniStack (replacement for LocalStack)(ministack.org) |
But, for anybody else who needs a quick fix - you can pin to the `community-archive` tag and it should unblock you quickly:
https://hub.docker.com/layers/localstack/localstack/communit...
Same reason I wince when people say things like "we just use SQLite in tests, but our real db is mysql/psql/etc"
The test results have no merit if they are testing against a glorified mock.
I briefly looked at localstack to see how they implemented the Kenesis api and other than a `KINESIS_ERROR_PROBABILITY` option to simulate rate limiting, they did not implement any of the constraints.
The only things I can think of are that perhaps LocalStack was just a mess of a codebase that couldn't maintain velocity or attract contributors, or it just failed to steward new contributors or some such thing.
I secretly always hoped Amazon would buy out LocalStack and make it the official free local development environment for AWS work, but I guess it probably would reduce revenues spent on AWS based dev and test environments. The compatibility with the AWS CLI was mostly excellent in my experiences.
Hopefully this change was not just an short term attempt to lock in current enterprise customers by shoring up existing income streams. That'll only work in the VERY short term.
It's not difficult to forsee the inevitable customer drain to free competitors or private one-shots easily produced by genai from publicly available AWS SDK code. Maybe they're already feeling that pressure and that's all this change is. I hope not.
AFAICT, they have no appreciable moat to retain customers long term. For example, I have absolutely no interest in their "Pods" or even their console UI, so thosr aren't keeping me around forever. For their sakes I hope they're still shopping themselves around and didn't take some VC poison pill with preconditions for killing the community edition. Really It's anyone's guess though.
https://github.com/Nahuel990/ministack/blob/a1b1d20a27d2238d...
This one is 7 days old.
I'm eager to have a localstack replacement, but these are a long way off from being mature enough. I suppose this is just the new state of software? Shiny website, big claims, AI coded, insufficiently tested.
Already lying or totally unreviewed AI slop ?
If you go on Reddit, there are at least a dozen AI "vibe coded" shitty local stack alternatives being posted daily. Whats special about this??
What’s different? IDK, you could try the "dozen AI vibe coded shitty local stack alternatives" and post it on your blog
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?
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
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.
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
Interesting, I've had the opposite experience. Every single AWS service I've ever tried to build tests around with LocalStack has run into compatibility issues. Usually something works in LocalStack but fails when it hits the real endpoint.
I guess the CLI itself has mostly worked, its more the LocalStack service not behaving the way the real service is documented/works.
Something more realistic would be:
+-----+
| foo |
+-----+
To be that guy for a moment: those are not ASCII as those characters are not in the standard 7-bit ASCII set. The closest you get to rounded corners with just ASCII is something like:
/-----\ .-----.
| bah | or | bah | (the latter usually looks best IMO, but that can depend on font)
\-----/ `-----'
> is already a red flag
I wouldn't call using box-drawing characters a red flag, I've known people use them this way for years and do so myself. The LLM generates them because they were in its training data because people use them. It might be something to consider amongst other flags but I don't consider it a strong signal on its own. The red flag for me is the alignment - if you are going to have your documentation ghostwritten at least make the effort to do a cursory editing pass afterwards.
In particular my issues were: - missing range fetches (probably in place now) - Missing version support in various places - bugs wrt to the handling of versioned objects across api calls
My needs are not super mainstream, but I was better off using RustFS in this case. A single lightweight fake would be preferable though.
But we can still do that ourselves, dynamically interrogating the real thing and comparing it to the fake.
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.
As far as I'm concerned the social contract (“the rules”) has already been broken by people taking insufficient care, and my reaction to that is a healthy one from the PoV of self-preservation. Acting in good faith works both ways, or it doesn't.
Well said, polluting hacker news with low effort slop for self promotion cannot be good faith. The rules are enforced on commenters but good faith is not expected for submissions somehow