LocalStack and AWS Parity Explained
localstack.cloud
LocalStack and AWS Parity Explained
1–10 of 40 posts
Re: LocalStack and AWS Parity Explained
#2While 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 very well where needed, for instance, DynamoDB[1]
If it was without that, I think it would be a lot less useful and way less easier to adopt, so I think its just as important to the story.
Why on earth AWS doesn't have their own first party emulators for everything I still don't understand to this day. I credit that for why Firebase & GCP are easier to use, because they have a good local development story for alot of their services (Firebase in particular has an emulator suite for nearly all their services)
Re: LocalStack and AWS Parity Explained
#3How 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…
I guess the main difference is that frameworks like Serverless provide a great experience if you fully buy into their way of doing things (i.e., implement your application assets in the Serverless YAML DSL, etc), whereas LocalStack is a generic platform that works on the API emulation level, hence easily integrates with most tooling out of the box.
Making the switch from Serverless to, say, AWS CDK, or AWS SAM, or Architect framwork may not be as seamless - however, for each of these frameworks you can always run the local emulation natively on LocalStack. This can help reduce the overall vendor lock-in effect that a lot of application development frameworks come with.
In fact, LocalStack also provides an integration with Serverless [0] - among many other tools [1].
Re: LocalStack and AWS Parity Explained
#4How 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…
I use it for stuff like SecretsManager and Cognito testing (as well as for S3). I don't use it for RDS emulation at all, and just stick a stock postgres container in that spot to achieve local development.
Re: LocalStack and AWS Parity Explained
#5Re: LocalStack and AWS Parity Explained
#6How 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…
Great point. Fully agree that providing a first-class local development experience is critical to the overall story of application development frameworks. I guess the main difference is that frameworks like Serverless provide a great experience if you fully buy into their way of doing things (i.e., implement your application assets in the Serverless YAML DSL, etc), whereas LocalStack is a generic platform that works…
Some background, with SST we connect your local environment to the services deployed to AWS and just run the Lambda functions locally: https://docs.sst.dev/live-lambda-development
Re: LocalStack and AWS Parity Explained
#7Earlier quoted context omitted.
Great point. Fully agree that providing a first-class local development experience is critical to the overall story of application development frameworks. I guess the main difference is that frameworks like Serverless provide a great experience if you fully buy into their way of doing things (i.e., implement your application assets in the Serverless YAML DSL, etc), whereas LocalStack is a generic platform that works…
I'm biased but for local development, I prefer to emulate the least amount of AWS services. You don't have to deal with any gotchas while going to prod. Some background, with SST we connect your local environment to the services deployed to AWS and just run the Lambda functions locally: https://docs.sst.dev/live-lambda-development
Re: LocalStack and AWS Parity Explained
#8How 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…
Under the hood, serverless uses DynamoDB Local which is the same AWS-provided DynamoDB emulator that LocalStack uses.
Re: LocalStack and AWS Parity Explained
#9I used LocalStack quite a bit at my last gig. It sure is nice to be able to use Terraform to spin up the same infra on my laptop, and test against that. It reduced the number of developer sandboxes we needed to have in AWS. I sure do wish AWS would go the GCP route and offer an emulator. I prefer to use that in E2E automation that's run in CI/CD pipelines.
Re: LocalStack and AWS Parity Explained
#10I used LocalStack quite a bit at my last gig. It sure is nice to be able to use Terraform to spin up the same infra on my laptop, and test against that. It reduced the number of developer sandboxes we needed to have in AWS. I sure do wish AWS would go the GCP route and offer an emulator. I prefer to use that in E2E automation that's run in CI/CD pipelines.