True - but the datacenter burning still hits you where it hurts if your entire Kubernetes cluster is living in that datacenter.

Whereas if you make a point of spinning up each Linux box on different datacenters (and even perhaps different providers) you are at least resilient against that.

Using advanced tooling doesn't remove the need to do actual planning beyond "oh I have backups" - you should be listing the risks and recoveries for various scenarios - though being able to handle "AWS deleted all my servers because I returned too many things via Amazon Prime" means you can also handle any lesser problem.

>Also, I assume sales force engineers aren’t SSHing into each shard and running docker-compose manually on each one.

Nothing wrong with that if all you have is 10-15 shards (or whatever your annoyance upper limit is).

Might even be faster and cheaper than spending hours learning/debugging/figuring out edge cases on something else.

But there’s an upper limit, right? And you’ll probably hit it somewhere before you pass 100bn USD ARR?

IME you'll hit it around $500,000 USD ARR. But again, situations vary. I've worked projects where hours long scheduled downtime at the weekend was acceptable. So easy!

A whole datacenter on fire, come on, what are the odds?

Oh, wait! Nevermind...

The first draft of any new product will be totally fine with just one Linux box.

Why?

Because the first draft has no users.

Once you have some paying users, yes - figure out what service guarantees those users want or need and put some effort into meeting them.

But, prior to having users, anything but pretty minimal infrastructure is waste.

Having an off-site backup of your data is a no-brainer at any level of complexity.