Software Infrastructure 2.0: A Wishlist
erikbern.com
Software Infrastructure 2.0: A Wishlist
1–10 of 202 posts
Re: Software Infrastructure 2.0: A Wishlist
#2We still have that customer but we have learned a very valuable & expensive lesson.
Being able to test in production is one of the most wonderful things you can ever hope to achieve in the infra arena. No ambiguity about what will happen at 2am while everyone is asleep. Someone physically picked up a device and tested it for real and said "yep its working fine". This is much more confidence inspiring for us.
I used to go into technical calls with customers hoping to assuage their fears with how meticulous we would be with a test=>staging=>production release cycle. Now, I go in and literally just drop the "We prefer to test in production" bomb on them within the first 3 sentences of that conversation. You would probably not be surprised to learn that some of our more "experienced" customers enthusiastically agree with this preference right away.
Re: Software Infrastructure 2.0: A Wishlist
#3It’s silly to complain that AWS doesn’t have a service that allows any random programmer to deploy a globally scalable app with one click. For one thing, you aren’t AWS’s primary target audience. For two, the class of problems that can be solved with such simple architectures is actually pretty small. But for three, it’s not actually even possible to do what you’re asking for any random code unless you are willing to spend a really fantastic amount of money. And even then once you get into the realm of a serious number of users or a serious scale of problem solving, then you’ll be back into bespoke-zone, making annoying tradeoffs and having to learn about infra details you never wanted to care about. Because, sorry, but abstraction is not free and it’s definitely not perfect.
Re: Software Infrastructure 2.0: A Wishlist
#4Heck, who voted up this article...
This article is like the NTF frenzy, it's fine, but it's going to be baseless because it's looking too far in the future.
Re: Software Infrastructure 2.0: A Wishlist
#5Re: Software Infrastructure 2.0: A Wishlist
#6The refusal to acknowledge that software will never be anything beyond executable data on some kind of computer, somewhere, is why most web-based software is so slow and shitty.
Having someone build the server and assign your code to run on it does not change that one (pun intended) bit.
Re: Software Infrastructure 2.0: A Wishlist
#7Looks like someone who had not spend enough time to review modern computing history. Heck, who voted up this article... This article is like the NTF frenzy, it's fine, but it's going to be baseless because it's looking too far in the future.
In fact I think a lot of this optimism is in dire need of a couple of baseball-bat hits to the kneecaps.
> But things are rarely built to optimize for developer productivity.
Well, these a-holes abandoned Rails in favor of serverless-react-lambda-script. They made their bed, now they must lie in it.
Re: Software Infrastructure 2.0: A Wishlist
#8The desire to go "truly serverless" and pretend the computer does not actually exist is absolutely delusional. The refusal to acknowledge that software will never be anything beyond executable data on some kind of computer, somewhere, is why most web-based software is so slow and shitty. Having someone build the server and assign your code to run on it does not change that one (pun intended) bit.
The JVM is something that comes quite close actually, but it lacks a few environment features and configuration/specification options to fully cover the space that most people need, hence why everyone is using docker now. But if you think about it: most people don't really want to use docker. It's just the best option currently.
Many don't care what OS they run on, because they don't rely on any specific OS functionality. This is exactly what should be improved for running code that can operate on a higher abstraction.
Re: Software Infrastructure 2.0: A Wishlist
#9Testing in 'production' has been possible for a while: Heroku has Review Apps, and Render (where I work) has Preview Environments [1] that spin up a high-fidelity isolated copy of your production stack on every PR and tear it down when you're done. [1] https://render.com/docs/preview-environments
If you're intereseted, I wrote a thing attempting to cover some of the options ~6 months ago, but recognize that there has been a fair amount of change in the space since then (I really should update the post). [thing: https://www.nrmitchi.com/2020/10/state-of-continuous-product...]
Re: Software Infrastructure 2.0: A Wishlist
#10Testing in 'production' has been possible for a while: Heroku has Review Apps, and Render (where I work) has Preview Environments [1] that spin up a high-fidelity isolated copy of your production stack on every PR and tear it down when you're done. [1] https://render.com/docs/preview-environments
There are a variety of other, similar Preview Environment offerings out there, and most PaaS offer their own options built in. If you're using a PaaS with a built-in solution, you'll almost always be better off using theirs. A lot of the difficulty comes when you've "outgrown" a PaaS for one-reason-or-anyother, and need to try to back-fill this functionality in a production-like fashion. If you're intereseted, I wrot…
1. Specify a TTL on inactive PRs
2. Pick less expensive plans for preview services.