Localstack integrations: Big impediments and deployment slowness for REST services

Platform
1

Hey everyone,

I’m pretty new around here. My team and I started diving into LocalStack a couple of weeks ago, aiming to streamline our AWS dev work locally. We’ve been genuinely excited about what LocalStack offers, but we’ve run into a couple of roadblocks that are making things tough for us:

We’re facing some challenges that have us resorting to workarounds, slowing our deployment process more than we’d like. And honestly, we’re trying to avoid unnecessary expenses, especially if it means our workflow gets bogged down instead of streamlined.

Building and deploying REST APIs is a staple for us, so it feels like we’re hitting a snag on something that should be fairly straightforward. We’re hoping these issues can get a bit more attention. It’s not just for our sake—getting these smoothed out seems like it’d benefit anyone working with REST APIs on LocalStack.

We understand the complexities of what you’re doing here, and it’s impressive. But these problems are holding us back from fully committing to LocalStack and leveraging it to its full potential. A fix would not only help us move forward but also strengthen our confidence in making LocalStack a key part of our development setup.

Could we maybe get these issues looked into sooner rather than later? It’d make a huge difference for us and likely for others in similar boats. We’re all about finding ways to work smarter, and with your help, I believe we can overcome these hurdles together.

Appreciate all the work you folks do and looking forward to being a part of this community.

Thanks for considering

2

Generally we currently recommend adapting a destroy + deploy workflow over updating a deployed stack due to some major issues in our update flow that will take major effort in implementing/fixing. It’s going to be a big focus point for us this year to bullet-proof CloudFormation updates, but until then I’d recommend trying to re-create stacks :+1:

We’re already working on fixing the immediate issues you’re facing though, just be aware that resources that you think you’re updating might not actually have the proper state you’d expect.

3

I appreciate the transparency regarding the current recommendations, It’s reassuring to know that the issues we’ve encountered are being actively worked on, and I understand the complexities involved in these enhancements.

However, I’d like to share a couple of challenges that the suggested destroy + deploy workflow presents for our specific use case:

  1. Large Scale Deployment: Our infrastructure includes about 150 REST endpoints, organized into 20 different stacks representing our microservices. Deploying this entire infrastructure through LocalStack with CDK takes roughly 20 minutes. This duration raises concerns about the efficiency and practicality of adopting a destroy and redeploy strategy, especially in a dynamic development environment where frequent updates are common.

  2. Data Persistence Concerns: A significant hurdle with the destroy + deploy approach is the potential loss of data in RDS and DynamoDB. For a development environment, maintaining some level of data persistence across updates is crucial. While backup scripts could be a workaround, it adds complexity and overhead with frequent deployments, deviating from the seamless development experience we aim for. Using localstack state export/import might be a solution but it would go against your suggestion.

Given these points, I’m seeking further advice:

  • Are we perhaps misusing LocalStack for a project of our size and complexity? Is LocalStack better suited for smaller-scale projects, or are there best practices for managing larger, more complex environments like ours?

  • Is there any way to optimize the deployment time with LocalStack, or strategies to manage data persistence more efficiently without resorting to full environment resets for every update?

Any insights or recommendations on how to navigate these challenges would be greatly appreciated. We’re committed to integrating LocalStack into our development workflow and are looking for ways to make it work as smoothly as possible for our project’s scale and needs.

Thanks again for your support and for the incredible work on LocalStack. Looking forward to any suggestions or guidance you can provide.

4

Are we perhaps misusing LocalStack for a project of our size and complexity? Is LocalStack better suited for smaller-scale projects, or are there best practices for managing larger, more complex environments like ours?

It’s definitely pushing the boundaries in terms of typical deployment sizes we’ve seen, but we’ve also seen larger ones! Your use case is absolutely in the realm of what LocalStack should support.

The concrete issue in your use case right now seems to be the lack of UPDATE support in CloudFormation as well as the naive strategy of our deployment engine which currently performs resource deployments sequentially. We should be able to speed this up significantly in the future by executing individual resource operations as much in parallel as possible.

You can of course also make use of the state export/reset feature as well as CloudPods to seed resource state into your application, but be aware that this will also currently not merge existing state in a single account/region/service pair. It’s a great tool for seeding state though and should be a lot faster than seeding via CDK.

the seamless development experience we aim for
This is also our aim for LocalStack, so I’d love to work more closely with you on this. You can reach out to us on our Community slack if you want! Would love to get more insight into your use case, concrete resources that you’re trying to deploy, etc.