Don’t Build for Uptime - Build for Outage
The internet was supposed to be resilient. Built to route around failure. Then came the cloud and with it, the promise that you no longer had to think about uptime. Someone else would worry about the hardware. Until they didn’t. Suddenly, the problem wasn’t “out there” anymore.
We’ve been here before. AWS us-east-1 has gone down so often it might as well be folklore. I remember during the pandemic, being online late that evening, only to get a Slack message from a client: their services had stopped working. “Even Google is offline,” I replied. Sounds absurd, but try explaining to your customer why their app forgot how to talk to itself. You can’t point to a root cause when there’s no root. Just silence. And with it: lost trust, lost revenue and slow erosion of credibility.
Still, the response is often tribal. Either you buy the sticker “multi-cloud everything” and build Rube Goldberg pipelines across providers or you stick with the one-cloud-to-rule-them-all fantasy, as if concentration isn’t a risk until it’s already ruined your quarter. But the truth is simpler and more boring: resilience works best without religion.
Multi-region is table stakes now. You can’t keep pretending it’s fine to run production in one availability zone or let your global control plane live in Northern Virginia just because it’s cheaper that way. But multi-cloud? That’s a different beast. Technically feasible, operationally hard, rarely worth it unless you’re buying freedom as a feature. Because that’s what it is: a hedge. Against outages, against lock-in, against being forced into roadmap decisions that aren’t yours. It’s not about having perfect symmetry across platforms, it’s about knowing you could leave if you had to.
Tools like Vercel and Cloudflare hint at a nicer future. They solve a very real problem: nobody wants to orchestrate failovers and nobody wants to pay for a team that sits and waits for them to happen. They wrap complexity in clean interfaces, auto-distribute your assets and generally make sure you stay online more often than not. But don’t be fooled, most of them still run on the same hyperscaler infrastructure. You’ve added abstraction, not independence. That’s fine if you understand the trade. Dangerous if you don’t. They’ve realized the issue to. Even those providers have noticed that they have to become more resilient against single points of failure.
And then there’s another conversation we keep avoiding in Europe. Because while we like to talk about autonomy, we still run most of our critical infrastructure on US companies. The reasons are maturity, tooling and talent. The alternatives aren’t mature enough yet to carry serious load and everyone knows it. This isn’t sustainable forever. You can’t build a sovereign digital strategy while piping your traffic through Silicon Valley. At some point, we have to stop treating resilience as just a tech issue and start seeing the structural problem.
If you’ve been through an outage that mattered, you know. You know the feeling of staring at a dashboard that won’t load and realizing there’s no fix, no restart. You can only wait and hope. Maybe lie a little. After that, you stop architecting for uptime and start architecting for failure. You design with the assumption that the tools you trust will fail you eventually. If you haven’t had that moment yet, it’s coming. The question isn’t if your provider will fail. It’s whether your business will survive when it does.
I’ve been the architect, sat beside the architect and cleaned up after the architect. Everything here was learned the hard way and in production.
