Multi-cloud is a negotiating position, not an architecture
Running on two providers is a commercial decision with an engineering bill. It is worth making — but only with the bill in front of you.
Multi-cloud is usually justified on two grounds: resilience and leverage. The resilience argument is weaker than it sounds. The leverage argument is stronger than engineers like to admit. Neither is an architectural principle, and treating multi-cloud as one produces systems that are portable in theory and mediocre in practice.
The resilience case, examined
Full provider outages are rare and usually regional. Most serious incidents originate in your own configuration, your own deployment, or a single service you depend on heavily — none of which a second provider protects you from unless you are running genuinely active-active, which very few organisations are.
What multi-cloud more commonly produces is a doubled operational surface: two identity models, two networking models, two sets of quotas and failure modes, two on-call knowledge bases. That is more ways to have an incident, staffed by a team that now knows each platform half as well.
The leverage case, taken seriously
Commercially, the picture is different. A credible ability to move workloads changes renewal conversations, and the discount is real. But credibility is the operative word: a provider can tell the difference between a customer who has actually run production elsewhere and one holding a slide about portability.
That credibility has a price, and the price is the abstraction layer, the duplicated tooling, and the managed services you decline to use because they exist on only one platform. Those declined services are usually the largest cost and the least discussed — you are paying, in engineering time, for the option to leave.
A more honest framing
- Decide whether the goal is resilience or leverage. They imply different architectures and conflating them produces a system that achieves neither.
- Price portability explicitly, including the managed services you will forgo and the engineering time to maintain abstraction.
- Consider partial strategies: a primary provider for most workloads, with one meaningful system elsewhere, buys much of the leverage at a fraction of the cost.
- Be honest about team capacity. Depth on one platform generally outperforms breadth across two, particularly during incidents.
- Revisit the decision on renewal cycles rather than treating it as permanent architecture.
The defensible version
None of this means single-provider concentration is free. Genuine lock-in exists, prices do move, and organisations have been caught. The point is that multi-cloud is a commercial hedge with an engineering premium, and hedges should be bought deliberately, sized against the risk, and reviewed — not adopted as an architectural conviction and then quietly resented by the people who maintain it.
Let's build the system your business will run on next.
Tell us where it hurts. We'll bring the architects, engineers, and delivery model to fix it — and scale it.