Live data from Hacker News

LocalStack and AWS Parity Explained

localstack.cloud

31–40 of 40 posts

Re: LocalStack and AWS Parity Explained

#31

LocalStack is cool, but don't forget that you always have an alternative to build mock infrastructure in front of your AWS deps. Don't call S3 deps directly - implement a higher abstraction using only the APIs you actually call and back it with your local filesystem (for example). It's not a _lot_ of work, and making your dev/prod differences more explicit can make debugging much easier.

It's work unrelated to your project, doesn't add any value.

Besides, it's reinventing the wheel.

And it's certainly cheaper to run local dev/tests against the real AWS S3 infra than paying the time to mock it with your local filesystem...

Re: LocalStack and AWS Parity Explained

#32

Earlier quoted context omitted.

Quoted post unavailable.

Mocks and adaptations such as localstack and serverless can be equally leaky or incomplete. You don't really know until you hit the real stage if what you've got is ready.

I've had issues with LocalStack in the past.

Decided it wasn't worth the savings compared to running against the real AWS services.

Re: LocalStack and AWS Parity Explained

#33

How does LocalStack compare to something like serverless[0], which lets you also have locally run abstractions over services? While I realize the most obvious difference being that serverless is also a deploy framework that "abstracts" the cloud, I think one of its primary benefits of adoption is that it also does a good job (in my experience, but I have not yet impelemented things deeply with it) emulates services v…

> Why on earth AWS doesn't have their own first party emulators for everything

Because they want you to pay for local development, not only production.

Google offers an emulator because otherwise no one would and they need to catch up with AWS, which has, what, 4x their market share?

AWS offers local emulators for services they need to catch up, like Lambda and DynamoDB.

Re: LocalStack and AWS Parity Explained

#35
post #33

How does LocalStack compare to something like serverless[0], which lets you also have locally run abstractions over services? While I realize the most obvious difference being that serverless is also a deploy framework that "abstracts" the cloud, I think one of its primary benefits of adoption is that it also does a good job (in my experience, but I have not yet impelemented things deeply with it) emulates services v…

> Why on earth AWS doesn't have their own first party emulators for everything Because they want you to pay for local development, not only production. Google offers an emulator because otherwise no one would and they need to catch up with AWS, which has, what, 4x their market share? AWS offers local emulators for services they need to catch up, like Lambda and DynamoDB.

I was excited when you said local Lambda emulator, but SAM just looks like a wrapper around https://github.com/lambci

Re: LocalStack and AWS Parity Explained

#36
post #31

LocalStack is cool, but don't forget that you always have an alternative to build mock infrastructure in front of your AWS deps. Don't call S3 deps directly - implement a higher abstraction using only the APIs you actually call and back it with your local filesystem (for example). It's not a _lot_ of work, and making your dev/prod differences more explicit can make debugging much easier.

It's work unrelated to your project, doesn't add any value. Besides, it's reinventing the wheel. And it's certainly cheaper to run local dev/tests against the real AWS S3 infra than paying the time to mock it with your local filesystem...

I disagree about the "doesn't add value" part when talking about introducing an abstraction over the AWS sdk: with mocks, it allows one to simulate failures, hung connections, and reproduce bugs without trying to contort an actual AWS account into the bad configuration that one might encounter in the real world

Your assertion about "cheaper" is also only true if one remembers to tear down all those resources when finished testing against them

Re: LocalStack and AWS Parity Explained

#37
I admire the goal of localstack and have used it a few times in the past.

I always prefer tools that also work locally for development.

However, especially for software development there is more than just API parity. You'll end up with many unexpected behaviours when developing in a fully mocked environment. I doubt it will always behave like the real AWS

Re: LocalStack and AWS Parity Explained

#38
post #32

Earlier quoted context omitted.

Mocks and adaptations such as localstack and serverless can be equally leaky or incomplete. You don't really know until you hit the real stage if what you've got is ready.

I've had issues with LocalStack in the past. Decided it wasn't worth the savings compared to running against the real AWS services.

Depending on how far in the past that was it might be worth it to revisit. Especially in the last year lots of things have changed.

Re: LocalStack and AWS Parity Explained

#39
Would be great to have a single table that shows supported services vs. tiers. At the moment I have to scroll through 8,000 services AND their features to try and decipher if I'll need a paid plan right from the start.

Re: LocalStack and AWS Parity Explained

#40

Earlier quoted context omitted.

Thanks for the detailed reply. Would I be able to take most, if not all, of my existing Terraform code and use it to stand up my topology in LocalStack? If so, that would be quite useful.

yes, if you pay for localstack Pro, and "maybe" if you don't. they have a list of services they emulate on their site. Here is the list: https://docs.localstack.cloud/aws/feature-coverage/

Thanks very much!
Post reply on HN