4 ms·

I really don't see how any clone is going to manage to do what localstack couldn't - maintain compatibility with tons of AWS services while not getting paid for

I really don't see how any clone is going to manage to do what localstack couldn't - maintain compatibility with tons of AWS services while not getting paid for it. If this were viable, why would it not have worked before? 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.

switchbak 6mo ago
"LocalStack was just a mess of a codebase" - very true. 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.
- sysguest 6mo ago
  idk maybe AWS should create one? 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
  - justincormack 6mo ago
    It hasnt really been a barrier to entry though has it, cloud adoption is doing just fine.
  - switchbak 6mo ago
    I wouldn’t hold my breath. They do have a dynamo db fake, but they don’t even release the code for it! Perhaps they’re concerned about making it really easy to clone their stuff. But we can still do that ourselves, dynamically interrogating the real thing and comparing it to the fake.
- mastercomputer 6mo ago
  What are the typical problems you mentioned with Floci? I just went into their repo, and the community is very active; I see a lot of contributions. I'm not sure what you mean by typical problems.
4m1rk 6mo ago
I suppose (among many other things) LLMs are changing this. We no longer need that many contributors when we can use AWS docs, intercept AWS API calls and give it to AI agent to mimic. Of course, contributors are still needed for maintaining tests and validations.
- yieldcrv 6mo ago
  and then the maintainer goes on a rant about accurate but agentically coded pull requests and doesn’t merge it
nnucera 6mo ago
Hello! We won't have the broad coverage that Localstack has... we're not aiming to be the "next Localstack"... just want to keep the core services that were available for free in the LS community up to date. If you’re looking for larger services like MWAA, sorry, but we won't be supporting them.... Most core AWS services don't receive many updates anyway (their APIs don’t change drastically or frequently)
- evil-olive 6mo ago
  > We won't have the broad coverage that Localstack has... we're not aiming to be the "next Localstack" 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?
  - nnucera 6mo ago
    If you’re looking for a Localstack alternative, it’s often because you were using the community tier... In that case, Ministack can serve as a drop-in replacement... otherwise, the price reduction in LS might already address your needs
deleted 6mo ago
[deleted]
mikeocool 6mo ago
Personally, I would get value out of really solid compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) with a light weight gui interface and persistence. 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.
- petcat 6mo ago
  > getting into esoteric features 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
  - drzaiusx11 6mo ago
    I'd put ALL the ones listed above: SQS, S3, KMS, DynamoDB, EC2, RDS, Redis in the required "core" services column, and also throw in IAM, SNS, and SecretsManager as well. Those are all table stakes imho. 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.
  - mikeocool 6mo ago
    Interesting — those are the ones that depending on the case, approximating them with local redis/postgres/vms without the AWS specific APIs on top is often good enough — because my app is just talking to them over native protocols anyway. 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.
jillesvangurp 6mo ago
That's true if you assume making these things is manual work. But of course with well documented API service and AI coding tools, making a functional local equivalent of any given service is not all that hard.
- hrmtst93837 6mo ago
  [flagged]
  - justincormack 6mo ago
    I am currently implementing S3, with correct error handling for edge cases. Its been about a month and I have almost the whole API surface done, with some gaps (you actually need a broader surface eg some IAM, KMS encrytion needs a persistence layer so only done sse-c so far). Close to the point where you could drop it in as a local emulation tool, its a sub 9MB binary (Rust). 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.
    - hrmtst93837 6mo ago
      [flagged]
      - justincormack 6mo ago
        Not really, the main thing they could change is the order in which errors are checked when there are multiple errors, but even a lot of that is not likely to change, eg html based stuff comes first. There are actual reasons for a lot of the subtleties, plus they have to have a stable contract for all the success cases as people rely on it. And its not hard to update, I have 800 or so tests against AWS that run in a few minutes.
        hrmtst93837 6mo ago
onion2k 6mo ago
If this were viable, why would it not have worked before? 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.

switchbak 6mo ago

"LocalStack was just a mess of a codebase" - very true. 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.

sysguest 6mo ago
idk maybe AWS should create one? 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
- justincormack 6mo ago
  It hasnt really been a barrier to entry though has it, cloud adoption is doing just fine.
- switchbak 6mo ago
  I wouldn’t hold my breath. They do have a dynamo db fake, but they don’t even release the code for it! Perhaps they’re concerned about making it really easy to clone their stuff. But we can still do that ourselves, dynamically interrogating the real thing and comparing it to the fake.
mastercomputer 6mo ago
What are the typical problems you mentioned with Floci? I just went into their repo, and the community is very active; I see a lot of contributions. I'm not sure what you mean by typical problems.

4m1rk 6mo ago

I suppose (among many other things) LLMs are changing this. We no longer need that many contributors when we can use AWS docs, intercept AWS API calls and give it to AI agent to mimic. Of course, contributors are still needed for maintaining tests and validations.

yieldcrv 6mo ago
and then the maintainer goes on a rant about accurate but agentically coded pull requests and doesn’t merge it

nnucera 6mo ago

Hello! We won't have the broad coverage that Localstack has... we're not aiming to be the "next Localstack"... just want to keep the core services that were available for free in the LS community up to date. If you’re looking for larger services like MWAA, sorry, but we won't be supporting them.... Most core AWS services don't receive many updates anyway (their APIs don’t change drastically or frequently)

evil-olive 6mo ago
> We won't have the broad coverage that Localstack has... we're not aiming to be the "next Localstack" 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?
- nnucera 6mo ago
  If you’re looking for a Localstack alternative, it’s often because you were using the community tier... In that case, Ministack can serve as a drop-in replacement... otherwise, the price reduction in LS might already address your needs

deleted 6mo ago

[deleted]

mikeocool 6mo ago

Personally, I would get value out of really solid compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) with a light weight gui interface and persistence. 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.

petcat 6mo ago
> getting into esoteric features 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
- drzaiusx11 6mo ago
  I'd put ALL the ones listed above: SQS, S3, KMS, DynamoDB, EC2, RDS, Redis in the required "core" services column, and also throw in IAM, SNS, and SecretsManager as well. Those are all table stakes imho. 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.
- mikeocool 6mo ago
  Interesting — those are the ones that depending on the case, approximating them with local redis/postgres/vms without the AWS specific APIs on top is often good enough — because my app is just talking to them over native protocols anyway. 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.

jillesvangurp 6mo ago

That's true if you assume making these things is manual work. But of course with well documented API service and AI coding tools, making a functional local equivalent of any given service is not all that hard.

hrmtst93837 6mo ago
[flagged]
- justincormack 6mo ago
  I am currently implementing S3, with correct error handling for edge cases. Its been about a month and I have almost the whole API surface done, with some gaps (you actually need a broader surface eg some IAM, KMS encrytion needs a persistence layer so only done sse-c so far). Close to the point where you could drop it in as a local emulation tool, its a sub 9MB binary (Rust). 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.
  - hrmtst93837 6mo ago
    [flagged]
    - justincormack 6mo ago
      Not really, the main thing they could change is the order in which errors are checked when there are multiple errors, but even a lot of that is not likely to change, eg html based stuff comes first. There are actual reasons for a lot of the subtleties, plus they have to have a stable contract for all the success cases as people rely on it. And its not hard to update, I have 800 or so tests against AWS that run in a few minutes.
      - hrmtst93837 6mo ago

onion2k 6mo ago

If this were viable, why would it not have worked before? 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.