Multi-cloud is usually sold as insurance and bought as ideology. The version that works is narrower and less romantic: decide which specific dependencies would genuinely hurt to unwind, abstract only those, and accept lock-in everywhere else because the alternative costs more than the risk.
Separate the three things people mean
Most disagreements about multi-cloud are really definitional. Three distinct strategies get the same label:
- Portability. One workload that could move providers if needed. Costs the most, used the least.
- Distribution. Different workloads on different providers, each chosen on merit. Common, sensible, and not really "multi-cloud" in the architectural sense.
- Redundancy. The same workload running actively across providers. Very expensive, justified for a small number of genuinely critical systems.
Being explicit about which one you are buying prevents paying redundancy prices for a distribution benefit.
What lock-in actually costs
Lock-in is not binary; it varies enormously by layer, and the exit cost is what matters:
| Layer | Switching cost | Worth abstracting? |
|---|---|---|
| Compute (containers) | Low — Kubernetes is genuinely portable | Already portable; no extra work |
| Object storage | Low-moderate — S3 API is a de facto standard | Thin wrapper at most |
| Relational databases | Moderate — portable engine, painful migration | Use standard engines, avoid proprietary extensions |
| Identity and IAM | High — semantics differ fundamentally | Usually accept |
| Managed data warehouse | High — dialect and operational model differ | Accept, or standardise on open table formats |
| Serverless / event glue | Very high — programming model is proprietary | Accept, isolate behind your own interfaces |
| Frontier model APIs | Low-moderate — interfaces converging | Thin adapter is cheap and worth it |
The pattern: abstract where abstraction is nearly free, accept lock-in where abstraction is expensive, and reduce blast radius instead. A generic abstraction over serverless event routing typically costs more in lost capability than the migration it was meant to enable.
Data gravity decides the architecture
Compute moves easily. Data does not. Egress charges, transfer time, and consistency requirements mean the data's location tends to determine everything else.
Two rules that survive contact with reality:
- Keep compute next to data. Cross-provider chatter between an application and its database is slow and expensive. If the data is in one provider, the workload lives there.
- Split at natural domain boundaries. Multi-cloud works when a whole bounded context — its data and its services together — sits with one provider, and integration happens through well-defined asynchronous interfaces. It fails when a single transaction spans providers.
For EU enterprises this cuts a useful way: sovereignty-sensitive domains can sit with an EU-controlled provider while general workloads stay with a hyperscaler, provided the split follows a domain boundary rather than a technical layer.
Patterns that hold up
Portable core, proprietary edge
Business logic in containers on Kubernetes, using standard engines. Proprietary managed services at the edges — queues, identity, observability — reached through your own interfaces. Migration then means rewriting adapters, not the domain.
Open table formats for analytics
Storing analytical data in Parquet with Iceberg or Delta metadata in object storage decouples data from query engine. Multiple engines can read the same tables, and switching becomes a procurement decision rather than a migration programme. This is the highest-leverage portability decision available today.
Model adapter for AI workloads
Provider APIs for language models have converged enough that a thin internal interface — with per-provider adapters — costs little. The payoff is real: price and capability move fast, and the ability to route by task, cost, or data sensitivity is worth more than the abstraction costs. Keep the interface narrow; do not try to abstract every provider-specific feature.
Infrastructure as code, per provider
Use one tool across providers, but do not chase a single abstract module that deploys anywhere. Provider-specific modules with a shared pipeline and shared conventions gives most of the operational benefit without the lowest-common-denominator trap.
What it costs
Be honest in the business case:
- Expertise. Two providers means two sets of deep operational knowledge. This is usually the dominant cost and the most underestimated.
- Egress. Cross-provider data movement is charged and adds up quickly. EU Data Act provisions have pushed providers to reduce switching charges, which helps exit economics but does not make routine cross-cloud traffic free.
- Lowest common denominator. Insisting everything run anywhere forfeits the managed services that make a provider worth using.
- Security surface. Two IAM models, two network models, two audit pipelines. Misconfiguration risk rises more than linearly.
A decision procedure
- Name the driver. Regulatory requirement, concentration risk, negotiating leverage, capability gap, or acquisition legacy. If none applies, single-cloud with disciplined architecture is the better answer.
- Set an exit objective per workload. "Recoverable within 90 days" and "portable within a week" are different architectures at different prices. Most workloads need the former.
- Map dependencies by exit cost. Abstract only the high-cost, high-likelihood ones.
- Draw the split on domain boundaries. Never mid-transaction.
- Rehearse it. An untested exit plan is a document, not a capability. Restore to the alternative provider once a year, or accept that the plan is aspirational.
Common questions
Does Kubernetes give us portability?
For the compute layer, largely yes. But applications depend on storage classes, load balancers, identity, and secrets management, all of which are provider-specific. Kubernetes moves the lock-in rather than removing it — which is still useful, just not the whole answer.
Is multi-cloud required for regulatory resilience?
Frameworks such as DORA require credible exit strategies and concentration-risk management for critical functions. They do not mandate running everywhere simultaneously. A documented, tested exit plan usually satisfies the requirement at a fraction of the cost of active redundancy.
What about sovereignty specifically?
Treat it as a per-flow classification rather than a whole-estate decision. Most organisations find a minority of flows genuinely require EU-controlled infrastructure. Routing those to a sovereign provider while keeping the rest on a hyperscaler is usually the right cost/risk balance.
Where do teams most often overreach?
Building an in-house abstraction over managed services. It consumes real engineering capacity, ages badly, and delivers a migration path nobody ever exercises. Isolate instead: keep provider-specific code in one place with a clear interface, and accept the dependency.
The short version
Decide whether you want portability, distribution, or redundancy, and price them differently. Abstract only where abstraction is cheap — containers, object storage, open table formats, model APIs. Accept lock-in in identity and event glue, and contain it. Split on domain boundaries, follow data gravity, and rehearse the exit. Multi-cloud is a set of deliberate, workload-level trade-offs, not a posture.