Most enterprises did not choose multi-cloud. They accumulated it.<\/p>\n
One team picked a provider for its data platform. Another standardised on a different one for developer tooling. An acquisition arrived with its own estate. At some point the spread across providers was wide enough that someone wrote “multi-cloud strategy” on a slide, describing after the fact what had happened by drift. The narrative that followed sold portability, resilience, and vendor leverage. The operating reality delivered fragmented tooling, duplicated skills, inconsistent security, and a cost picture no single team could explain.<\/p>\n
Multi-cloud as a pitch is compelling. Avoid lock-in, place each workload on its best-fit provider, keep negotiating leverage, survive a provider outage. As a statement of strategic intent, none of that is wrong.<\/p>\n
The problem is that every one of those benefits is an operating capability, not a procurement decision. Portability is not having two providers. It is the discipline to build so that workloads can actually move, which most organisations never pay for. Resilience across providers means running and testing failover across two control planes, two identity models, and two security postures. Vendor leverage exists only if you can credibly move, and you can only credibly move if you built for it. The pitch describes outcomes. The outcomes depend on work the pitch leaves out.<\/p>\n
The two are easy to confuse on a spend report and easy to tell apart in practice. Intentional multi-cloud places workloads deliberately, behind a common control plane, with one identity model, one security baseline, and one cost and observability model spanning providers. The organisation chose the complexity and built the capability to manage it.<\/p>\n
Accidental sprawl is the opposite. Providers were chosen locally, by different teams, at different times, each with its own tooling, its own access model, and its own definition of secure. Nothing spans the estate except the invoice. This is the common case, and it is not a weaker version of a strategy. It is the absence of one, presented as a strategy because the alternative is admitting the spread was never designed.<\/p>\n
Accidental multi-cloud rarely announces itself as a problem. It arrives as a series of locally reasonable decisions, each defensible on its own, and the cost shows up later as an aggregate nobody chose. The pattern is worth naming, because it is predictable.<\/p>\n
Every provider added to the estate adds a tooling stack to learn, an identity model to integrate, a security baseline to maintain, and a billing structure to decode. Two providers is not twice the work of one. It is the work of one, plus the integration and reconciliation between them, plus the load on a skills base that now has to be competent in both. Add a third and the connections multiply faster than the providers. Security is where this hurts most. A control enforced consistently on one provider and inconsistently on another is not a control. It is a gap with a compliance report attached, and the gap is exactly where an attacker, or an auditor, will find you.<\/p>\n
The cost is real, but it is diffuse, which is what makes it dangerous. No single invoice or incident captures it. It surfaces as slower delivery, recurring security findings, and a finance function that cannot answer basic questions about where the money goes. By the time the aggregate is undeniable, the sprawl is load-bearing, and untangling it competes with every other priority.<\/p>\n
Multi-cloud delivers its promised benefits only on top of an operating model built to carry them. That means unified identity and access across providers, a security posture that does not fork per cloud, a common observability and cost model so the estate can be seen as one thing, and a skills strategy that does not require every engineer to be fluent in every provider. Build those, and a second or third provider adds genuine optionality. Skip them, and each provider you add multiplies cost, fragments security, and stretches a skills base that was already thin.<\/p>\n
The sequence is what most enterprises get wrong. The operating model is the prerequisite, not the thing you bolt on once the sprawl becomes painful. Adopt first and integrate later, and the result feels like several single-cloud problems billed together, which is precisely how most multi-cloud estates feel today.<\/p>\n
The number of providers in an estate is the wrong thing to measure. The right thing is how much spans them: one identity model, one security baseline, one view of cost and operations. Where the only common thread is the finance team’s spreadsheet, the word strategy is doing a great deal of unearned work.<\/p>\n
The choice in front of most leadership teams is not which provider to add next. It is whether to build the operating model that turns the clouds already in the estate into genuine optionality, before adding one more that deepens the sprawl. Optionality is earned through that operating model, never bought with another contract, and the bill arrives whether or not the capability does.<\/p>\n","protected":false},"excerpt":{"rendered":"
Multi-cloud promises portability, resilience, and vendor leverage. Most enterprises arrive at it by drift rather than design, and inherit operational complexity instead of strategic optionality.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-10","post","type-post","status-publish","format-standard","hentry","category-executive-briefings"],"_links":{"self":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/10","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10"}],"version-history":[{"count":1,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/10\/revisions"}],"predecessor-version":[{"id":26,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/10\/revisions\/26"}],"wp:attachment":[{"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}