What is multi-cloud pragmatism?
Multi-cloud means running across more than one provider. The pragmatic view is that it is sometimes genuinely necessary — for resilience, regulation, or acquisitions — but often adopted for the wrong reasons, at a steep cost in complexity. The skill is telling the cases apart.
Why it matters
"Avoid vendor lock-in" sounds wise and pushes teams toward multi-cloud, but the abstraction layers it requires can cost more than any lock-in would. Knowing the real trade-offs lets you give honest advice instead of cargo-culting, which is exactly the judgment senior DevOps roles want.
What to learn
- Genuine drivers: resilience, compliance, data residency, M&A
- The cost of lowest-common-denominator abstractions
- Vendor lock-in: real risk versus overblown fear
- Portability with containers and Kubernetes
- Data egress costs between clouds
- Operational overhead of multiple providers
- Choosing one cloud well as the common default
Common pitfall
Going multi-cloud to dodge lock-in, then building an abstraction layer that uses only features common to all providers — losing the managed services that made each cloud worth using. You pay double the operational cost for less capability. Usually, committing to one cloud and using it well beats hedging across several.
Resources
Primary (free):
- Google Cloud — Multicloud · docs
- Martin Fowler — Don't get locked up avoiding lock-in · article
- CNCF — Cloud native landscape · tool
Practice
For a hypothetical product, write the case for and against multi-cloud: list the concrete drivers, estimate the added operational cost, and reach a recommendation. Be specific about what you would lose by using only common features. Done when you can defend either committing to one cloud or going multi.
Outcomes
- Name the genuine drivers for multi-cloud.
- Explain the cost of lowest-common-denominator abstractions.
- Assess vendor lock-in as a real, sized risk.
- Recommend for or against multi-cloud with reasons.