Move Back to Datacenters

> It's not just services like databases or other APIs applications hook into, it's the applications themselves, like accounting software or Microsoft Exchange and Office 365, etc...

That's a fair point!

I mean, there are some options out there like Odoo, or stuff like Nextcloud/Collabora, OpenProject and you can run your own mail server etc., but those will increasingly feel like bad ideas for someone who needs something that "just works" and also has deadlines to manage.

It's a bit like "Nobody got fired for choosing IBM", except nowadays with Microsoft/Google/Amazon cloud offerings, the Jira's of the world and so on.

The traveling analogies make no sense.

For most companies their software is their business. Take away the software and the company stops functioning.

Their employees aren’t just visiting their software every few weeks or so. They’re using it every day from morning to evening.

There is no travel involved. Your software is your home.

So really a better analogy would be renting vs buying your home. The rental comes with the furniture and for several things that might go wrong the landlord will come and fix it, whereas when you own the house, you have to buy the furniture and arrange it, and if anything goes wrong you are responsible for fixing it.

Of course, the analogy breaks down in many ways because when you’re on Prem you are buying established software with a support license so if something does fail the support license should provide as much, if not more service than you would get on AWS.

The entire analogy is completely pointless because it adds a layer of indirection for no reason other than for some reason tech people absolutely love making analogies to physical objects.

> The business case is that someone else is doing the infrastructure management for you.

Many business people believe that moving to cloud can reduce the headcount needed for managing the infra, but that is usually not what's happening. You will still need more or less the same amount of people to patch the OS and configure the networking, but with a slightly different skill set -- instead of Cisco IOS commands, they now need to deal with AWS transit gateway.

Every data center I worked with offers on-site remote hands that will rack new servers or replace hard drives or PSUs for you. There are also third-party companies that offers this service. Redundant power and air conditioning are the responsibility of the colocation provider and those are covered by the SLA. Those data centres do have generators on-site.

That said, configuring you top-of-rack switch is usually not covered by the co-location contract. This need to be done by a network engineer, usually the same person that would manage VPCs.

Yep, that's the compromise I came to as well at my solo bootstrapped SaaS. However, there are still some benefits of colocation that I would love to have: 1. ability to use M1 Mac minis as servers for specialized workloads, while having an identical developer setup for testing. This would really enable me to finetune, test, and squeeze out performance to the max and have the dream of a "single box" deployment serving hundreds of thousands of customers.

If you're treating cloud as a sort of 1:1 replacement of hardware infrastructure, then what you're saying makes sense.

But we don't ever "patch the OS." Our cloud provider does that for us. Upgrades and patching are automatic within the maintenance window. We deploy containers, the OS is just a platform layer that the cloud provider manages.

As for needing "more or less the same amount of people", that simply isn't true IME. I've seen startups with whole teams devoted to running systems in a datacenter, whereas cloud-based startups will often have one or two guys, possibly even part-time, dealing with their cloud requirements.

At larger companies, it can be harder to make this comparison, since you'll typically have a mixture of cloud and onprem. But if you look at teams with products deployed in the cloud, they'll often have much more frequent deployment, with better automation, and much less dependence on the always overcommitted infrastructure team(s).

> Every data center I worked with offers on-site remote hands that will rack new servers or replace hard drives or PSUs for you.

That's not very compatible with infrastructure as code. You're essentially saying "keep doing things the old inefficient way, it's not really that bad."

There are all sorts of failure scenarios that a managed cloud system can cover from completely automatically within minutes, that would require frantic calls to remote hands in the old world. And even when recovery isn't automatic, it may still require nothing more than some pointing and clicking to recover.

> instead of Cisco IOS commands, they now need to deal with AWS transit gateway.

> This need to be done by a network engineer, usually the same person that would manage VPCs.

These aren't comparable at all. Unless a company has some sort of very special networking requirements, they can set up VPCs with some pointing and clicking in the cloud provider's web UI. This is a far cry from the level of knowledge required to manage networks at the hardware level.