Multi-cloud is mostly a procurement strategy
Running on three clouds to avoid lock-in usually creates three lock-ins, each with its own invoice.
The case for multi-cloud is strong on a whiteboard and weak on a spreadsheet. Most organisations do not need portability across providers; they need the courage to leave one when the price stops making sense. Portability is an exit option, not an architecture.
The lock-in we pretend to avoid
Every cloud has proprietary services that are genuinely better than the portable alternative. Managed databases, serverless platforms, observability stacks, identity services, they are sticky because they are good. Wrapping them in an abstraction layer does not remove the dependency; it adds a new dependency on the wrapper. We have reviewed platform teams of six engineers whose entire job is maintaining an abstraction layer that exists to make three clouds look like one, for workloads that have run on the same single provider since the project started.
That team is not wasting time by accident. Somewhere in the founding architecture review, someone reasonably worried about lock-in, and the organisation solved for a risk that never materialised while paying for it every single sprint since. The abstraction layer becomes a tax on every new feature: nothing can use a native service until the wrapper supports it, which means the wrapper decides your roadmap instead of your customers.
The cheapest way to avoid cloud lock-in is to keep the exit cost visible. The most expensive way is to engineer a portability layer nobody asked for.
Where multi-cloud actually makes sense
- Regulatory data residency that a single provider cannot satisfy.
- Acquisition of a company already embedded in another ecosystem.
- Best of breed services: one provider's AI, another's object storage, a third's CDN.
- Negotiation leverage, but only if you can credibly move a real workload.
- Disaster recovery for a genuinely mission critical system, where the cost of a second provider is cheaper than the cost of a full regional outage.
None of those reasons require a uniform abstraction. They require boundaries. Pick the best service for each job, own the interfaces between them, and accept that some parts will be harder to move than others. That is honest architecture. It also tends to be cheaper, because you are not paying an engineering team to build and maintain a lowest-common-denominator layer that nobody outside the platform team ever sees.
The commodity alternative
The real freedom is not being on three clouds. It is knowing what it would cost to leave the one you are on. That means clean data contracts, containerised stateless workloads where it makes sense, and a quarterly review that asks whether the current provider is still winning on price, features, and support. Most organisations that do this discover their exit cost is measured in weeks, not years, and that knowledge alone gives them more negotiating leverage than a genuine multi-cloud deployment ever did.
We ran the numbers for a client who believed they needed full portability across two providers for negotiating leverage. Their actual annual cloud spend was €4.2 million; the abstraction layer, the duplicated tooling, and the two sets of specialist engineers cost them just under €900,000 a year. They had never once used the leverage, because moving the workload for real would have taken nine months and nobody was willing to sponsor that project. They cancelled the second provider within a quarter of seeing the comparison.
FinOps discipline over architecture theatre
The teams that get the best unit economics from cloud are rarely the ones with the most sophisticated architecture. They are the ones with the most disciplined tagging, the clearest ownership, and the willingness to have an uncomfortable conversation with a provider once a year about renewal terms. Multi-cloud, in our experience, is often adopted as a substitute for that discipline: it feels like a strategic hedge, but it is frequently a way of avoiding the harder work of actually managing one provider well.
- Tag every workload with an owner, a cost center, and a business metric before adding a second provider.
- Run the annual renewal negotiation as a real process with a credible walk-away, not a formality.
- Track committed-use discounts against actual usage quarterly; unused commitments are wasted leverage.
- Separate 'we could move' from 'we have moved something, ever' when reporting portability to the board.
What to change on Tuesday
- 01Audit your multi-cloud strategy. If no workload has moved in a year, you are paying for theatre.
- 02Keep three candidate workloads genuinely portable; the rest can use native services.
- 03Negotiate with one primary provider and use the others as benchmarks, not equals.
- 04Measure exit cost in weeks and euros, not in architectural purity.
- 05Compare the abstraction layer's engineering cost against the leverage it has actually produced.
More dispatches.
The catamaran is a computer at sea
Multihulls did not win because they are fast. They won because a stable platform lets sensors, models and crew think clearly.
The cat is now a connected device
Pet tech stopped being a gadget niche. It is a health data business with whiskers.
The incubator is a portfolio, not a factory
Ventures do not share a mould. They share a treasury, a network, and a discipline for killing things early.