Seeing all these horror stories, I can't help but wonder when people are going to switch back to on prem, or at least some hybrid. It's pretty apparent we can't trust cloud providers...
Look at all the banks shifting their infra to the cloud. Haven't heard anything bad happen from that. And their uptime and business requirements are as stringent as anyone else, even further scrutinized by regulators and auditors.
It won't go all back to on prem because cloud providers will slash their margins once they struggle to maintain growth, and doing so they'll diminish the advantages of on-prem/hybrid setups for a lot of people, and so we'll find some equilibrium or other.
I'd expect more emphasis on hybrid between multiple clouds rather than cloud vs. on prem to happen first. E.g. layers to threat more parts of cloud services as commodities.
I'm all for hybrid solutions, but mostly because it means you usually end up being able to cut the cost of on prem, colocation or managed servers even more relative to cloud setups because you can increase the utilisation rate (e.g. run your base load on cheap Hetzner servers but being able to spin up EC2 instances on short notice to take spices or handle failures up to and including all of Hetzner falling off the face of the earth). Most larger managed providers today also offers cloud services and many also offers colo services, so you can often easily mix and match as long as you're conscious off egress pricing which is often the biggest barrier to such setups today (especially if the big cloud providers are in the mix, though it's better than it was).
That said, I prefer not putting my eggs in one basket, and instead going the direction of putting in place layers to treat a multi-provider setup as one. In the past I've e.g. done zero downtime migrations between AWS->GCP->Hetzner that way, and also had systems split between actual on prem (as in a data room at our office), multiple colo's, dedicated servers at Hetzner, and a couple of VM providers where everything was transparent to our engineers (they didn't need to know on what continent a service ran unless doing performance optimisation or reliability engineering). We prepped to tie in AWS resources too, but it never become cost effective for that company to do so vs. the prices of the other providers used - it would have been if we had sudden extreme load spikes, but it was a business where traffic was linked closely to physical capacity at restaurants and nightclubs, and so traffic was very predictable.
Most companies aren't actually at the scale where they need cloud. Cloud comes with the benefit of minimal to no need for ops/devops, high uptime (when nothing goes wrong lol), integrated DDoS protections, APIs your junior devs can string together, and the illusion of infinite scaling.
In reality, it turns out you do need someone to effectively do ops, you don't have 99.999% uptime, your don't need most or any of those APIs, and you didn't need that promise of scaling after all.
With DDoS protection, on-prem hosting or independent dedicated hosting might be more economical and practical.
The other big benefit is auto scaling, in 2012 lots of companies would launch and be unable to meet traffic from a big push from reddit or HN or others. Today it’s rare to see a new product’s site go down due to a “hug of death.”
If you do in-colo hosting with leased servers you've already cut the big initial spend drastically (e.g. deploying to a new colo for a past employer involved buying a pair of switches and some cables), though you're still usually tied in to a lengthy contract. Doing managed servers usually comes with little to no upfront cost (sometimes a low setup fee) and often month-by-month contracts.
With respect to the on demand pricing benefit vs. monthly, my experience is that the price differential is so steep vs. the cheaper managed hosting providers that it's only usually viable for loads that run less than ~6 hours a day. Most sites do not have a variable enough load to justify the engineering cost to use cloud to handle their normal day/night cycle that way - usually the variations are too small. Some do.
But note that this only pays for itself if your base load is not on a cloud setup, as the base load tends to dominate and the base load cost of most cloud setups is high enough not to be outweighed by the increased flexibility vs. a pure managed/colo/on prem setup.
It gets worse for cloud: If looking for the most cost effective, they're not competing against a pure managed/colo/on prem setup, but against a hybrid setup which can auto-scale into the cloud but usually won't. If you e.g. deploy containers, all your need is to tie cloud instances automatically into an overlay network and feed data from your monitoring system into a tool that adjust min/max instances in for an autoscaling group in AWS when load exceeds a threshold, for example.
For a typical "pure" on prem setup you'd usually aim for the daily peaks to rarely exceed 50% of on prem capacity. Maybe a bit more if you have a very predictable business, or even less if your traffic is very unpredictable.
But if you add capability to that setup to spin up and tie in cloud instances to handle peaks, and you can push that into 90%+, or even above 100% - basically whichever number turns out most cost effective. Usually if you optimise that for cost, this means you'll end up with a setup which almost never spins up cloud instances, but which is now vastly cheaper relative to a pure cloud setup because it's gained the benefit of auto-scaling at a far higher load factor than would be safe in a pure on prem/managed setup.
For a 10-20 person company that's a huge expense with not that much ROI.
That said, I think cost is more likely to drive change here than fear over billing - most people pick lover cost over risk mitigation far more often than they'd like to admit.