It's impressive what Localstack has been able to do to keep up with AWS.
However for my own projects, we consider local development like this an anti-pattern. IaC tools like Terraform/CDK/SST make it easy to spin up environments for each developer in the cloud. This may sound crazy at first but would recommend giving it a shot.
If you're fully taking advantage of managed AWS services the best development environment is running everything in AWS. There's definitely some friction but you reduce the "was working on my machine but not in production" situations.
> However for my own projects, we consider local development like this an anti-pattern. IaC tools like Terraform/CDK/SST make it easy to spin up environments for each developer in the cloud.
But what do you test your IAC against? If you consider using something like Terratest, then combining it with LocalStack means you can run Terratest nearly instantly and test your IAC.
Plus developers being able to run "AWS" locally menas they, too, benefit from the instant feedback loop. That alone is a good enough reason to use LocalStack, but there are other massive positives: no credentials to a real AWS account to leak; no developers spinning up some new AI tool 'cos it looks cool; and more.
The credentials are the API keys and secrets, not the login and passwords.
One improper setting in IAM and an accidental pastebin or GitHub means half the automated hacks have access to the same thing the IAM user does.
I did this once on accident by hitting control-V instead of control-c and overwriting my censored version before pasting into GitHub so other people could save the 4 hours of tedious scripting I had to do. GitHub sends an email within minutes, but I was already miles away from a computer when I got the email...
It’s not really that impressive all things considered. Localstack is effectively Python’s Boto library (an AWS mocking tool) running as a server.
In turn, all of the AWS APIs are defined by a kind of JSON schema document, so there’s not really any reverse engineering going on.
I consider Localstack somewhat toxic in most projects because it shows the the developer didn’t understand how to contract test.
Furthermore, doing anything more than contract testing with AWS is a fool’s errand. The problem you face with Localstack is that it gives you an inaccurate model of how AWS actually works. As a general rule, AWS APIs are asynchronous, as in their side effects are not atomically bound to the request you’re making (sans some certain S3 actions); while Localstack is invariably synchronous.
I'd like to better understand how you define local development specifically as an "anti-pattern". What are your criteria for using that term, and what other examples might also fall into a similar category?
I'm not sure I agree with the linked article, are there any other (accessible, and existent in the present) resources you used to arrive at this decision?
For one, the article assumes the tools you use to replicate your production environment locally aren't accurate; with localstack, they are accurate. It's seamless, truly. I recommend you give it a try instead of spending the extra cash to have your developers deploy into the cloud constantly.
Another thing to note is that this seems only true for a specific architecture, if you're writing serverless functions. Not everyone is or should be doing that, so I'm not sure "you should always test in the cloud" applies as a "context free" rule.
Finally, it sounds like the author had a lot of trouble getting his local environment to work. Maybe folks who have a bit more experience working with the technologies involved in their services don't have that problem, and it's a little arrogant to assume that, just because you had a problem, that it's a problem for everyone else, too.
Overall, I just don't think commenting, "This service nice, but using it is an anti-pattern" was quite as productive of a comment, in general, as you meant it to be.
However for my own projects, we consider local development like this an anti-pattern. IaC tools like Terraform/CDK/SST make it easy to spin up environments for each developer in the cloud. This may sound crazy at first but would recommend giving it a shot.
If you're fully taking advantage of managed AWS services the best development environment is running everything in AWS. There's definitely some friction but you reduce the "was working on my machine but not in production" situations.