Use one big server

Do we know if it shows cold spares? That's all I think is needed at a minimum to avoid the problems I'm talking about, and I doubt they would note those if they don't necessarily have a hostname.

I like One Big (virtual) Server until you come to software updates. At a current project we have one server running the website in production. It runs an old version of Centos, the web server, MySQL and Elasticsearch all on the one machine.

No network RTTs when doing too many MySQL queries on each page - great! But when you want to upgrade one part of that stack... we end up cloning the server, upgrading it, testing everything, and then repeating the upgrade in-place on the production server.

I don't like that. I'd far rather have separate web, DB and Elasticsearch servers where each can be upgraded without fear of impacting the other services.

It completely depends on what you doing. This was pointed out in the first paragraph of the article:

> By thinking about the real operational considerations of our systems, we can get some insight into whether we actually need distributed systems for most things.

If you're hosting on-prem then you have a cluster to configure and manage, you have multiple data centers you need to provision, you need data backups you have to manage plus the storage required for all those backups. Data centers also require power, cooling, real estate taxes, administration - and you need at least two of them to handle systemic outages. Now you have to manage and coordinate your data between those data centers. None of this is impossible of course, companies have been doing this everyday for decades now. But let's not pretend it doesn't all have a cost - and unless your business is running a data center, none of these costs are aligned with your business' core mission.

If you're running a start-up it's pretty much a no-brainer you're going to start off in the cloud.

What's the real criteria to evaluate on-prem versus the cloud? Load consistency. As the article notes, serverless cloud architectures are perfect for bursty loads. If your traffic is highly variable then the ability to quickly scale-up and then scale-down will be of benefit to you - and there's a lot of complexity you don't have to manage to boot! Generally speaking such a solution is going to be cheaper and easier to configure and manage. That's a win-win!

If your load isn't as variable and you therefore have cloud resources always running, then it's almost always cheaper to host those applications on-prem - assuming you have on-prem hosting available to you. As I noted above, building data centers isn't cheap and it's almost always cheaper to stay in the cloud than it is to build a new data center, but if you already have data center(s) then your calculus is different.

Another thing to keep in mind at the moment is even if you decide to deploy on-prem you may not be able to get the hardware you need. A colleague of mine is working on a large project that's to be hosted on-prem. It's going to take 6-12 months to get all the required hardware. Even prior to the pandemic the backlog was 3-6 months because the major cloud providers are consuming all the hardware. Vendors would rather deal with buyers buying hardware by the tens of thousands than a shop buying a few dozen servers. You might even find your hardware delivery date getting pushed out as the "big guys" get their orders filled. It happens.

Could confirmation bias affect your analysis at all?

How many companies went cloud-first and then ran out of money? You wouldn't necessary know anything about them.

Were the scaling problems your single-server customers called you to solve unpleasant enough put their core business in danger? Or was the expense just a rounding error for them?