101–110 of 132 posts
Earlier quoted context omitted.
+100 Another example to add to your list - the new AWS CLI v2: > don't force me to download a 30MB binary with embedded Python interpreter baked in, please just give us a pip package instead! ;)
Or better yet, rewrite it in Go to avoid both the fat blob and python dependency management at the same time!
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…
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…
I’ve been saying for a couple of years whoever builds a tool to one click deploy an AWS alike to run on local bare metal has built the next billion dollar a year company. I know of a lot of big shops that are desperate to get out of the cloud due to 7-8 figure AWS bills but their software and engineering is too tightly wound into AWS tooling.
But AWS is huge. They employ thousands of engineers. Granted most of the complexity is due to its huge huge scale, but still it has too many features to do what youre asking. And then there are AWS exclusives like DynamoDB. Yes there are open source public/private cloud alternatives like OpenStack but they won't solve the problem of lock in and you'd still have to change all your tooling.
Earlier quoted context omitted.
It's kind of stunning that starting with fully open technologies we build another closed mainframe on top of it. All that's old is new again.
Agreed, that's really stunning - seen the analogy of cloud as the "modern mainframe" come up more and more recently. I guess the (business) reason is that the centralized computing model enables enormous economies of scale. (Makes perfect sense from an operations point of view.) What it seems to miss in the current incarnation/iteration, though, is the "power of distribution" - leveraging the fact that local compute…
Now it's exactly the same thing in AWS. My next guess is that you're going to be running production code on fleets of devs computers because you don't have to get extra budget for AWS next financial year to afford spinning up another instance.
Earlier quoted context omitted.
+100 Another example to add to your list - the new AWS CLI v2: > don't force me to download a 30MB binary with embedded Python interpreter baked in, please just give us a pip package instead! ;)
Or better yet, rewrite it in Go to avoid both the fat blob and python dependency management at the same time!
Most of the code is just a thin veneer over that information...
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…
> 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" loca…
The feedback loop is definitely a problem but projects like SST return the instant feedback loop to you.
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…
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?
Paul Swail has spoken a lot about this and has an upcoming book around the concept: https://serverlesstestinghandbook.com/
Earlier quoted context omitted.
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?
Others have written about this better than I can, here's an article: https://dev.to/garethmcc/why-local-development-for-serverles... Paul Swail has spoken a lot about this and has an upcoming book around the concept: https://serverlesstestinghandbook.com/
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.