The point is - I can do any changes I need to the underlying resources programmatically and near instantly, without ever having to talk to anyone. Including cloud provider staff. Or rather, automation can.
There may exist some colo where I can get a server(or storage, or network cards or anything else) added in minutes over an API call but I haven't heard of any. That's usually found on the VPS side.
> Fault tolerant architectures can be be deployed on colocated hardware too.
They can, usually requiring that you specifically setup redundancies and the like. Which is something that you already have for many cloud offerings. Your automation and redundancies sit on top of the vendor's existing redundancies.
For instance, the EBS volume I mention. It is not a disk. Its not even just an array. It's a far more sophisticated abstraction. If there are issues, it can automatically fetch blocks from your snapshots(if the blocks are unmodified, something they also keep track of). Not happy with spinning disks and want a SSD? No need to place a service order to your colo provider, just send an API call and this will be automatically migrated to SSDs without your applications ever noticing the difference (other than the response time) and with zero downtime. Your software could even do this if it notices that the workloads require it.
If an AWS datacenter goes up in flames the systems I manage will still function (and will self-heal, assuming they even get affected, which for big zones they might not be). I don't have to talk to anyone. I can be sleeping and this will still happen.
It's a completely different level of abstraction.
If you want to compare a big cloud provider with either your own datacenter or colocation facility, there's a big disparity in scale. At a minimum, you would have to compare with several interconnected datacenters or colos. You still don't get the abstraction layer.
It's all missing the point though - I was pointing out that software doesn't necessarily need to have 24x7 staff, as the parent poster was pointing out, even for exceptional (but predictable) issues. Sure, you need someone on-call to handle completely unexpected events, but I don't think that was the point being made.