What you will take away
- Most multi-cloud is accidental - acquisitions and one-off decisions, not strategy.
- Abstracting to the lowest common denominator wastes what you pay each provider for.
- Portability is cheapest at the application layer, not the infrastructure layer.
The reasons that hold up
Data residency requirements that only one provider meets in a given country. A specific managed service that is materially better for one workload. Acquisitions that arrived with their own estate. Genuine regulatory or contractual obligations around concentration risk.
The reason that rarely holds up on inspection is negotiating leverage. The discount gained is usually smaller than the cost of running two of everything, and providers know whether your workloads are genuinely movable.
The abstraction trap
The instinct is to build a layer that hides provider differences so anything can run anywhere. In practice that layer becomes a product of its own to maintain, and it restricts you to the features every provider shares - which is exactly the set of capabilities you are not paying a premium for.
An abstraction that lets you leave any provider usually means you never used what made any of them worth choosing.
The workable alternative is portability where it is cheap - containers, standard runtimes, business logic that is not written against a proprietary API - and deliberate provider-specific usage where it earns something.
Place workloads, do not spread them
Assign each workload to one provider for a stated reason, and keep its data with it. The failure mode to avoid is a single application whose components are split across providers and chat across the boundary, paying egress and latency on every call.
- One provider per workload, with the reason written down.
- Data stays with the workload that owns it.
- Cross-provider traffic is asynchronous and deliberately minimal.
- A named owner per estate, because unowned accounts are where cost and risk accumulate.
What has to be unified
Identity, above everything. One directory federating into all providers, so joiners and leavers are handled once. After that: consolidated logging and monitoring so an incident is investigated in one place, a single tagging and cost-reporting standard, and a network design that is documented rather than accumulated.
Pipelines should be provider-aware but not duplicated. One deployment path with different targets is maintainable; three separate systems that drift are not.
Be honest about the people cost
Multi-cloud means expertise in every provider you use, and cloud skills are deep rather than transferable. A team that is excellent on one platform is competent at best on the second, and competent is where the expensive mistakes live.
If the strategy is real, fund the training and the second on-call rota. If it cannot be funded, the honest answer is to consolidate - a well-run single-provider estate beats a thinly-staffed multi-cloud one on cost, reliability and security.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
