Also, I assume sales force engineers aren’t SSHing into each shard and running docker-compose manually on each one.
Obviously you need Goldilocks infrastructure - not too little, but not too much.
All I’m saying is it doesn’t go ‘one Linux box, one Linux box, one Linux box, reach Facebook size, build your own data center’.
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.
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.
Oh, wait! Nevermind...
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.
Many problems can be solved with other methods - especially if you do NOT have global all-sync’d requirements like Twitter and Facebook. Many SaaS (example: Salesforce) are perfectly acceptable sharding customers to particular instances thereby limiting downtime if something goes wrong.
And always keep in the back of your mind that the largest VPS or servers are very performant today - having to scale sideways may be masking inefficiencies in the code.