Live data from Hacker News

Software Infrastructure 2.0: A Wishlist

erikbern.com

1–10 of 202 posts

Re: Software Infrastructure 2.0: A Wishlist

#2
I love the test-in-production illustration. This is a fairly accurate map of my journey as well. I vividly remember scolding our customers about how they needed a staging environment that was a perfect copy of production so we could guarantee a push to prod would be perfect every time.

We 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

#3
While it’s a good idea to lay out a vision for the future of infrastructure as a service, it’s annoying to read this sort of article that seems to believe it ought to be simple to provide true serverless magical on-demand resources for random code. Fact is it’s a lot more complicated than that unless you’re just a small fry without any really hard problems to solve.

It’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

#5
Testing 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

Re: Software Infrastructure 2.0: A Wishlist

#6
The 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.

Re: Software Infrastructure 2.0: A Wishlist

#7

Looks 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.

Yeah, I just love his breathless dismissal of the incumbents (Guess I'm a neo-luddite!)

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

#8
post #6

The 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.

It is not.

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

#9
post #5

Testing 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 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

#10
post #9
post #5

Testing 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…

Great article and certainly worth an update! Specifically for Render, you can now:

1. Specify a TTL on inactive PRs

2. Pick less expensive plans for preview services.

Post reply on HN