Hybrid and Multi-Cloud

Two problems, two different fixes

A regional bank keeps its core ledger on a mainframe in its own data center, because moving 40 years of transaction history and a strict regulator's audit trail is not something you do casually. But the bank also wants its new mobile app to run on infrastructure that can absorb a holiday shopping spike without buying servers it uses 3 days a year. That is one problem: connecting infrastructure you cannot leave with infrastructure you want to add.

A different company, a fast-growing social app, has already committed to a multi-year, multi-billion dollar contract with one cloud provider and watches that single contract dominate its infrastructure budget. Losing negotiating leverage, and being one contract dispute away from a painful renegotiation, is a different problem: depending on a single vendor for everything.

The deployment models from the previous lesson do not have a name for either fix on their own. Hybrid cloud and multi-cloud are what organizations build when public, private, and community cloud each solve part of the problem, but no single one solves all of it.

Hybrid cloud: 2 infrastructures, bound together

NIST defines a hybrid cloud as "a composition of 2 or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability." Read that carefully: the pieces stay separate. The bank's mainframe does not become part of AWS, and AWS does not become part of the bank's data center. What connects them is a layer, built specifically to move data and workloads between the two, that makes the boundary as invisible as possible to the people using it.

That connective layer is a real product category, and several vendors sell exactly this. AWS Outposts extends AWS hardware, APIs, and services into a company's own data center, so a team can run the same tools on-premises and in the public cloud without learning 2 different platforms. Microsoft's Azure Arc and Azure Stack HCI do the equivalent for Azure: managing on-premises servers, Kubernetes clusters, and databases as if they were Azure resources, wherever they physically sit. In both cases, the point is portability, moving an application or a dataset across the boundary without rebuilding it.

Back to the bank: the ledger stays on the mainframe it cannot move, and the mobile app runs in the public cloud where it can absorb a traffic spike overnight. Hybrid cloud is what lets both halves work as one system instead of 2 unrelated ones, sharing identity, monitoring, and in some cases data, across the line between them.

Multi-cloud: more than one public provider

Multi-cloud means something narrower than it sounds: using public cloud services from 2 or more separate providers, AWS and Google Cloud, for instance, rather than committing everything to one. Google Cloud's own definition keeps it simple: an organization uses cloud computing services from at least 2 public providers to run its applications.

The social app from the opening is a real pattern, not a hypothetical. Snap Inc, the company behind Snapchat, committed to spend at least $2 billion with Google Cloud over 5 years starting in 2017, a contract so large that Snap's own IPO filing named it as a major financial risk. Snap's response was to add a second, separate commitment: at least $1 billion to AWS by the end of 2021, for what its filing called "redundant infrastructure support." Snap's infrastructure today runs as microservices spread across both providers, so no single vendor's pricing, outage, or contract renewal can dictate every term.

Vendor lock-in is the main reason organizations go multi-cloud, but it is not the only one. Some services genuinely are stronger on one provider, so a team might run its data warehouse on one cloud and its machine learning pipeline on another to use each provider's strongest offering. Data residency rules in some countries require certain data to stay within that country's borders, and the fastest provider region there is not always the one a company already uses everywhere else.

The boundary: hybrid or multi-cloud, and why "both" is common

Hybrid and multi-cloud answer different questions, and a scenario usually only tests one at a time.

A company can be both at once, and increasingly is. Picture a hospital network again: patient records stay on private, on-premises hardware for compliance, the hybrid half, while its billing system runs on AWS and its telehealth video service runs on a different provider chosen for lower latency in certain regions, the multi-cloud half. Nothing about the definitions forces a company to pick a lane.

One trap worth naming directly: running workloads in 2 different regions of the same provider, 2 AWS regions, for example, is not multi-cloud. Multi-cloud specifically means separate providers. Running in multiple regions of one provider is a resilience technique within a single cloud, a different concept covered later in this course.

A second misconception: multi-cloud does not automatically mean an application survives a provider's outage. Spreading unrelated workloads across 2 providers, one team's app on AWS, a different team's app on Azure, reduces contract and pricing risk, but if a single application only runs on one of those providers, that application still goes down when that provider does. True cross-provider resilience means actively architecting one workload to run on more than one cloud at once, which is harder and rarer than multi-cloud adoption numbers suggest.

Where this leaves you

Ask 2 questions, not one, before you label a setup. Does it include a private or on-premises piece connected to a public cloud? If yes, that is the hybrid half. Does it involve more than one separate public provider? If yes, that is the multi-cloud half. A setup can answer yes to both, one, or neither, and the label only matters because it tells you what problem the organization was actually solving: keeping something it cannot move, or refusing to depend on anyone it does not have to. The next topic leaves deployment models behind and turns to the question every one of these choices eventually runs into: what it actually costs.