The Origin of Multicloud: How Three Clouds Became the New Default

There was a moment around 2014 when picking a cloud felt like picking a religion. AWS people did not talk to Azure people. Azure people thought Google was for hobbyists. Google Cloud people thought everyone else was wrong about Kubernetes. The conventional wisdom held that an enterprise should pick a primary cloud, commit to it deeply, and minimise the operational drag of running on multiple platforms.

By 2024, that conventional wisdom had inverted. The 2024 Flexera State of the Cloud report found that 89 percent of enterprises were running on multiple clouds, and the average enterprise used three. Multicloud had not just become acceptable. It had become the default architectural pattern of the modern enterprise. This is how that shift happened.

Why this category had to exist

Through the late 2010s, single-cloud commitments started producing problems that the original architectural advice had not anticipated. The pain points below pushed multicloud from heretical to mandatory.

• <strong>Vendor lock-in at strategic scale.</strong> A single-cloud commitment meant accepting a single vendor's pricing trajectory, feature roadmap, and operational reliability for the long term. Boards began demanding genuine optionality before signing the next renewal.
• <strong>Egress costs as a hostage situation.</strong> Cloud providers priced data egress aggressively, making it financially impractical to move even a fraction of an estate off the primary cloud. Customers discovered the lock-in only when they tried to leave.
• <strong>Capability gaps between providers.</strong> No single cloud delivered the best answer for every workload. Analytics ran better on one platform, identity on another, AI workloads on a third. Forcing everything onto one cloud meant accepting suboptimal answers for parts of the estate.
• <strong>Single-cloud outage exposure.</strong> Major regional outages, including AWS us-east-1 in 2017 and 2021 and Azure in 2023, demonstrated that even hyperscalers fail. Mission-critical workloads needed a fallback that did not depend on the same provider's control plane.
• <strong>GPU and AI capacity scarcity.</strong> When generative-AI workloads exploded after 2022, no single cloud had enough GPU capacity to serve all demand. Multicloud GPU allocation became a hard procurement requirement, not an architectural preference.
• <strong>Mergers, acquisitions, and inherited clouds.</strong> Acquired companies arrived with their own cloud commitments. Forcing uniform single-cloud strategy meant rewriting workloads and breaking continuity. Multicloud absorbed the reality on the ground instead of fighting it.

Chapter 1 (2011-2014): The Single-Cloud Era

In the early 2010s, the typical enterprise cloud conversation was a vendor selection. AWS was the obvious choice for most net-new workloads. Azure was a sensible pick for Windows-heavy estates that wanted continuity with existing Microsoft licensing. Google Cloud Platform, launched in 2008 as App Engine and rebuilt as a full IaaS offering from 2013, was a distant third with a niche following.

The dominant strategic advice was to consolidate. Multi-cloud deployments were seen as a sign that an architecture team had failed to align on a single platform. Discounts compounded with scale, so concentrating spend on one provider produced better economics. Operationally, every cloud had its own console, its own APIs, its own networking model. Running on two clouds meant operating two of everything.

Vendor lock-in concerns existed, but they were treated as a tomorrow problem. The much larger concern in 2012 was getting any workloads into cloud at all. Architects who pushed for portability often found themselves outvoted by teams who needed to ship products this quarter.

Chapter 2 (2014-2016): The Second Cloud Appears

Two things changed by the mid-2010s. First, Azure matured. Under Satya Nadella's leadership from 2014, Microsoft repositioned Azure as a serious enterprise platform with credible IaaS, strong identity integration via Azure AD, and aggressive feature parity catch-up with AWS. Many large enterprises already had Microsoft enterprise agreements that included substantial Azure credits, making a second cloud essentially free at the margin.

Second, the lock-in concern became real. As workloads scaled in AWS, the cost of egress (data transfer out of AWS to anywhere else) became a meaningful line item. Re-architecting to leave AWS, even partially, started looking financially impractical. Procurement teams pushed back. The argument for a second cloud as negotiating leverage became compelling, and the implementations followed.

The second-cloud pattern of the period was usually pragmatic: AWS as the primary platform with new Microsoft-centric workloads or Office 365-adjacent applications on Azure. Or Azure as the primary with data and analytics workloads pulled out to AWS for specific services like Redshift. Strategic, deliberate, workload-by-workload. Not yet a coherent multicloud architecture.

Chapter 3 (2017): Kubernetes Changes the Conversation

The most consequential enabler of modern multicloud was not built by AWS, Microsoft, or Google for that purpose. It was Kubernetes, the open-source container orchestrator Google released into the wild in 2014. The first stable release in 2015 was followed by managed services from every major cloud: Google Kubernetes Engine (2015), Azure Kubernetes Service (2018), and Amazon Elastic Kubernetes Service (2018).

By 2017, Kubernetes had emerged as the de facto cross-cloud abstraction layer. An application packaged as a set of Kubernetes manifests and container images could in principle run on any cloud that offered managed Kubernetes. The portability was real, though not effortless. Differences in load balancers, persistent storage, identity, and ingress still required adaptation. But the cost of moving a workload from one cloud to another collapsed from years to weeks.

Kubernetes also unified the operational vocabulary across clouds. Platform engineers who had learned to operate one Kubernetes cluster could operate another almost regardless of underlying cloud. The operational overhead that had made multicloud impractical began to dissolve. The category was finally architecturally feasible, not just commercially desirable.

Chapter 4 (2018-2020): The Multicloud Toolchain Matures

The years between 2018 and 2020 saw a multicloud toolchain emerge that made the architectural pattern operationally sustainable. HashiCorp Terraform, first released in 2014, became the dominant infrastructure-as-code language across all major clouds. A single declarative configuration could describe resources in AWS, Azure, and Google Cloud, with consistent state management and pipeline integration.

Service meshes like Istio (Google, 2017) and Linkerd added a network-policy and observability layer that could span clusters across clouds. Multi-cloud observability platforms (Datadog, Grafana Cloud, New Relic) provided unified dashboards and incident response that did not require switching between three different consoles when something broke at 3 a.m.

Cloud-agnostic data platforms emerged in parallel. CockroachDB and YugabyteDB offered distributed SQL that could span clouds and regions. MongoDB Atlas, Confluent Cloud, and Snowflake operated as cross-cloud platforms with consistent APIs regardless of the underlying provider. By 2020, an enterprise could in principle build a fully cloud-agnostic stack from compute to data without writing significant glue code.

Chapter 5 (2021-2023): FinOps and the Strategic Multicloud

As multicloud became standard, a new operational discipline emerged to keep the architecture financially sustainable. FinOps, formalised by the FinOps Foundation in 2019, addressed a problem that had become impossible to ignore: multicloud spend was growing faster than predictable. Different clouds priced compute, storage, and network egress differently. Reserved instance commitments locked spend into specific providers. Surprise bills became a board-level concern.

FinOps brought engineering, finance, and procurement into a single operational rhythm. Workload placement decisions began considering not just performance but cost optimisation across providers. Some workloads belonged in AWS for specific services. Some belonged in Azure for licensing-included Windows workloads. Some belonged in Google Cloud for BigQuery or specific AI capabilities. The decision became granular and was revisited continuously.

Resilience benefits also became real. The most disciplined multicloud architectures could survive a region-wide outage in one cloud by failing over to another. The cost of that resilience was significant, but for high-value workloads (payments, trading, critical SaaS), the redundancy investment was easily justified. Multicloud stopped being only about lock-in avoidance. It was about strategic optionality.

Chapter 6 (2024-now): AI Reshapes the Multicloud Map

The generative-AI boom that followed ChatGPT's late-2022 release has reshaped the multicloud landscape again. GPU availability is no longer evenly distributed across clouds. AWS, Microsoft, and Google have each invested billions in different AI hardware partnerships (NVIDIA, AMD, custom silicon), and the workloads gravitate to wherever the GPUs are available with the right model access.

The model layer matters as much as the GPU layer. Azure OpenAI Service offers exclusive commercial access to OpenAI models. AWS Bedrock provides access to Anthropic, Cohere, and Meta models. Google Vertex provides access to Gemini. An enterprise that wants to use multiple foundation models for different use cases is, by definition, building a multicloud AI architecture.

What looked like an architectural compromise a decade ago has become a strategic necessity. The 2026 multicloud reality is that no single hyperscaler offers the best answer for every workload, and the cost of being locked into one is now higher than the operational overhead of running across three. The vocabulary of multicloud (placement, portability, FinOps, observability, sovereignty) has become as fundamental as the vocabulary of any single cloud platform.

What This Means for UAE Businesses Today

If you are operating in the UAE in 2026, multicloud is almost certainly already part of your environment, whether by design or by accident. The lesson from the last decade is that deliberate multicloud architectures dramatically outperform accidental ones. The difference shows up in cost, in resilience, and in the speed at which new capabilities can be adopted.

Three implications follow. First, treat workload placement as a continuous engineering discipline. Not every workload belongs in your strategic primary cloud. AWS Bedrock, Azure OpenAI, and Google Vertex each have different strengths. Latency-sensitive workloads belong where the user is. Sovereignty-sensitive workloads belong in the right jurisdiction. Cost-optimised workloads belong wherever the reserved-instance math works out best.

Second, invest in the multicloud control plane before you invest in the third cloud. If your organisation cannot deploy a workload, monitor it, and enforce policy on it consistently across at least two clouds today, adding a third will multiply the operational pain. Terraform, Kubernetes, a cloud-agnostic observability stack, and a clear FinOps practice are the unglamorous but decisive investments.

Third, plan for sovereignty as a multicloud question. UAE regulators increasingly require certain workloads to run inside the country and inside specific operational frameworks. Sovereign-cloud stamps from AWS, Azure, and Google operate as distinct logical clouds even when they sit within your primary provider's relationship. A well-designed multicloud strategy treats these as first-class destinations rather than special cases.

Where Artiflex IT Comes In

Artiflex IT has been designing, deploying, and managing cloud solutions across the UAE, Oman, and Saudi Arabia for over 14 years. We work with AWS, Microsoft Azure, Google Cloud, VMware, Nutanix, Veeam, Zerto, and the broader cloud ecosystem as the use case requires. We do not believe one platform wins every workload, but we do believe the right platform for a specific workload usually wins by a meaningful margin once the assessment is done honestly.

If you are partway through a cloud journey and not sure whether the next step is more public cloud, more private cloud, more hybrid integration, or something else entirely, we will tell you exactly what your current state looks like and what an honest plan for the next 18 months should be. No upselling, no theatre.