The Fragility of the Cloud
We did not eliminate the single point of failure. We just moved it somewhere we could no longer see it.
For a word that suggests weightlessness, "the cloud" describes something remarkably concrete: a limited number of enormous buildings, humming with servers, clustered in a handful of regions chosen for cheap power and cheap land. When people say their data "lives in the cloud," what they mean, more accurately, is that it lives in someone else's warehouse, on someone else's hardware, subject to someone else's outages.
A Smaller Web Than It Appears
The modern internet feels vast and decentralized because the number of things you can do on it keeps multiplying. But the number of places those things actually run has been quietly shrinking for two decades, consolidating into a small handful of infrastructure providers. A single company having a bad afternoon can take a meaningful fraction of the internet down with it — and periodically does.
The Redundancy Illusion
Ask any infrastructure engineer whether their systems have redundancy built in, and the honest answer is almost always yes — on paper. Traffic is designed to fail over between regions, data is designed to replicate across zones, and disaster recovery plans exist in careful documents that get reviewed once a year. What these plans consistently underestimate is correlated failure: the scenario where the thing that breaks is not a single server but a piece of shared infrastructure — a routing system, an authentication service, a configuration change pushed everywhere at once — that every one of the supposedly redundant regions depends on equally.
Redundancy protects against the failure you planned for. It does very little against the failure you didn't think to separate, because separating it would have cost more than the perceived risk justified at the time the system was designed. This is not negligence so much as a structural feature of how large systems get built under real budget constraints: true independence is expensive, and the appearance of independence is comparatively cheap.
Convenience Bought on Credit
None of this happened by accident or malice. Centralizing infrastructure is simply more efficient, and efficiency is what gets rewarded. Every business that outsources its servers to a handful of large providers makes an individually rational decision. It is only in aggregate that the rational decisions add up to a fragile whole — a structure that works beautifully until, briefly and all at once, it doesn't.
- Fewer companies now host a larger share of the internet's daily traffic than a decade ago
- A single regional outage can cascade across services that appear, to users, entirely unrelated
- Redundancy is technically possible but expensive, and rarely built out to the degree the marketing implies
Who Actually Pays for Downtime
When a major provider goes down, the cost does not fall evenly. A large company with an in-house engineering team absorbs an outage as an inconvenience and a line in a postmortem document. A small business running its storefront, its payment processing, and its customer support through the same affected provider can lose a full day of revenue with no equivalent internal capacity to route around the problem. The efficiency that centralization provides is real, but it is not distributed evenly, and neither is the risk that comes attached to it.
The Vocabulary of Reassurance
It is worth paying attention to the specific language infrastructure providers use after an outage, because the vocabulary itself performs a kind of reassurance independent of the technical content. Incidents are described as "degraded performance" rather than failure. Root cause explanations lean heavily on passive constructions — "a configuration was applied" rather than "we made a change" — that quietly obscure the human decisions involved. None of this is necessarily dishonest, but it does consistently frame outages as impersonal weather events rather than as the predictable result of specific architectural choices made, in the ordinary course of business, to prioritize cost and speed over the kind of redundancy that would have prevented the incident.
This framing matters because it shapes what customers and the public come to expect as normal. An outage described in the passive voice, resolved within hours, followed by a calm postmortem, reads as an acceptable cost of doing business at scale. Ten of these in a year, at ten different providers, start to look less like isolated incidents and more like the visible symptoms of an entire internet architecture that was built around a specific tradeoff — concentrate for efficiency, accept the occasional synchronized failure — that most users never explicitly agreed to and were rarely given the chance to opt out of.
What a More Honest Architecture Would Cost
It is worth actually pricing out what genuine independence between regions and providers would cost a typical business, because the number is instructive. Running fully duplicated infrastructure across two unrelated providers, with no shared dependencies at any layer, roughly doubles baseline infrastructure spend and adds meaningful engineering overhead to keep both environments truly in sync rather than silently drifting apart. For a large financial institution or a hospital system, this cost is frequently justified and, increasingly, mandated by regulators who have drawn the same conclusions this piece is drawing. For a small business running a storefront, the same architecture is usually not a realistic option, which means the fragility being described here is not evenly avoidable even for those who fully understand it.
What Fragility Asks of Us
This is not an argument for returning to server closets and self-hosted email. It is a case for honesty about what we actually built: not a resilient, distributed network immune to failure, but a highly efficient, highly concentrated one — fast and cheap most of the time, and occasionally, all at once, unavailable to almost everyone at the same time.