How does LocalStack fare against AWS Innovative Sandbox technology?
Hi @bran , thanks for asking this question! The AWS Innovation Sandbox is essentially a CloudFormation stack that creates a sandbox environment in your real AWS account, with certain IAM and network limitations applied. The sandbox is designed to be accessed from Amazon AppStream, a remote desktop setup.
LocalStack, on the other hand, is a cloud emulator (running as a Docker container) that provides a set of 70+ AWS services directly on your local machine. This is a fundamentally different approach, as with LocalStack all service interactions are happening on your local machine, without ever talking to the real cloud. For example, you can develop and execute Lambda functions, connect to SQS queues, write to DynamoDB tables, etc - all entirely on your local machine. LocalStack can also be used to run your automated integration tests in a CI/CD pipeline - making it very easy to spin up an ephemeral AWS-like environment to deploy your app and execute your tests against.
So, in comparison to AWS Innovation Sandbox, LocalStack provides the following:
- allows quick local development cycles (debugging Lambdas, without needing to redeploy on each change)
- quickly spinning up ephemeral environments that start up within a second (vs. several minutes on AWS)
- no AWS account required, no cloud costs incurred (all services emulated locally)
- no connectivity to cloud required (once all dependencies are loaded, LocalStack allows you to literally develop cloud apps offline)
More details as well as a Getting Started guide can be found in our docs here: https://docs.localstack.cloud
Hope that helps clarify things - please let us know if there are any other questions. Thanks!
Thanks for responding. Is the paid version of LS pay-as-you-go or pay-as-you-use model? I am trying to compare the full LS and SB from the economics point of view. I guess majority of people who are using LS are in the proof–of-concept phase, or learners. I think free LS is a clean winner for the rudimentary stub/skeleton kind of showing. But assuming a PoC may need a variety of smooth services (PoCs are usually an unknown territory) the paid LS version would be a must. On the other hand, SB together with nuking down everything capability could be a winner if the costs are approximately the same SB vs paid LS, or even if the SB cost is slightly higher due to the fact that SB is under dominion of a single individual who can now control the cost precisely as he progresses toward PoC completion. Of course, if the costs full LS vs SB are radically different in favor of the paid LS, the LS would be the winner as well.
The biggest drawback of AWS in the past was uncontrollable costs (that’s how I stumbled upon LS in the first place - the name did not stick in my mind for some reason, so after few months when I was googling for the concept again, I was searching under the name Sandbox and that’s how I stumbled on AWS Innovation SB).
Hi @bran , apologies for the delayed response. The paid version of LS (LocalStack Pro/Team) uses a seat-based subscription model - each developer using LocalStack would use their own API key, which is billed either monthly or annually (at a discount).
While a direct comparison with the costs in the real cloud is not always easy (as it heavily depends on the types of workloads, AWS services used, number of automated builds executed, etc), the clear advantage of using LocalStack is that the costs become predictable, as you rightly pointed out.
Also, on top of the mere financial/costs comparison, a lot of our users factor in the efficiency gains they are able to achieve by using LocalStack, for example:
- resources are spinning up rapidly locally (e.g., ~2 seconds for an RDS database in LocalStack, as compared to up to ~15mins on AWS) - this is especially critical if you want to foster a culture of continuous testing (which means frequently creating/destroying resource) which is becoming more and more important
- Lambda code can be executed and debugged locally, without ever needing to upload the Lambda function code to the cloud, resulting in extremely fast development feedback cycles
- it is very easy to create setups to quickly create ephemeral environments that can be easily replicated - creating a dev setup whenever a new team member joins, easily reproducing the same setup in each build of your CI pipeline, etc
In addition, LocalStack enables a number of use cases that facilitate day-to-day cloud development tasks as well as team collaboration. One example is Cloud Pods, a persistence mechanism that allows to take a snapshot of your entire local instance, and then easily share the state with team members, to achieve collaborative debugging. Given the nature of how a cloud environment works vis-a-vis a local emulator, this is something that completely sets LocalStack apart from the real cloud environment, because in LocalStack we can literally snapshot the entire state of your application, and easily recreate it on a different machine (or, for example, use it to preseed the test environment in a CI pipeline).
We’d be very happy to gain more insights and potentially also contribute to the business case you’re preparing. Please feel free to shoot us an email at info@localstack.cloud - happy to follow up on this topic and provide more guidance… Thanks!