Study Guide2,649 words

Unit 4.6 study guide — Hybrid and multi-cloud

Cloud Digital Leader › Unit 4 › Topic 6

Hybrid and multi-cloud

Study guide for Cloud Digital Leader, Unit 4 · Topic 6. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Discuss the business reasons for choosing hybrid or multi-cloud strategies and how Anthos enables these strategies.

Objectives, quoted from the exam guide:

  1. Discuss the reasons and use cases for why organizations choose a hybrid cloud or multi-cloud strategy.
  2. Describe the business value of using Anthos as a single control panel for the management of hybrid or multicloud infrastructure.

Hybrid and multi-cloud

Why an estate spans environments, and how one team runs it

Why — the business drivers Google names for hybrid and for multicloud, and whether the estate is meant to last. How — the single control panel the guide calls Anthos, which Google now delivers as fleet management in Google Kubernetes Engine.

Unit one asked which deployment model fits a scenario. This topic asks two different questions. The first is why: what actually drives an organization to run across its own data centers and one or more clouds, and whether it means that estate to be permanent or only a stage on the way somewhere else. The second is how: once an estate spans environments, what keeps it from becoming several estates run by several teams in several ways. The exam guide answers the second question with one word, Anthos. That name has since been retired — Google now delivers the same idea as fleet management inside Google Kubernetes Engine, or GKE — and this deck teaches the idea under both names, because the exam uses the old one and Google's documentation uses the new one.

Why organizations run hybrid or multicloud

A means to a business requirement — sometimes for good, sometimes for now

  • Permanent: meets a business objective the estate exists to serve
  • Temporary: a stage — a migration, a short project, a merger
  • Rarely a goal in itself; always a means to a business requirement
  • A single provider has real advantages it must outweigh

Worked example (synthetic). Two retailers merge. One runs on-premises, the other on a public cloud. Their first combined estate is hybrid — not because anyone chose hybrid, but because integrating IT comes before choosing a final architecture.

Google's Architecture Center opens this subject with a distinction the exam rewards. An organization can adopt a hybrid or multicloud architecture either as a permanent solution to meet specific business objectives, or as a temporary state to facilitate certain requirements, such as a migration to the cloud. Hold that split, because the right answer to a scenario often depends on which one it describes. Google is equally clear about the status of the choice: in general, a hybrid or multicloud architecture is rarely a goal in itself, but rather a means of meeting technical objectives driven by certain business requirements. So when an exam item asks why an organization went hybrid, the answer is a business requirement, never hybrid for its own sake. And the choice has something to beat. Google names the benefits of staying with a single cloud provider — reduced complexity, built-in integrations among services, and cost options like committed use discounts — and then says there are still scenarios where multicloud is worth it. The next two slides are those scenarios.

The drivers Google names, and where each points

Some drivers point to hybrid, some to multicloud, one to both

Business driverPoints toWhat Google says about it
Data sovereignty lawsBothA hybrid driver; and a second provider when the first has no local region in that country
Reduce capital expenditureHybridLower up-front IT spending, with cost disciplines such as FinOps
Flexibility and agilityHybridRespond to changing market demands
Unique capabilities per providerMulticloudUse new technologies without being limited to one provider's choices
Avoid vendor lock-inMulticloudAvoid being locked into a single cloud provider
ResilienceMulticloudMay cost more in the short term, but could prevent outages

Worked example (synthetic). An insurer expands into a country where its current provider has no local region, and the regulator requires data to stay in-country. The multicloud driver is sovereignty — not lock-in, which is the answer candidates reach for.

Google lists the drivers for each architecture separately, and the lists overlap in exactly one place. For hybrid, the common business drivers are heeding laws and regulations about data sovereignty, reducing capital expenditure or general information technology spending with disciplines like FinOps, increasing flexibility and agility to respond to changing market demands, and improving transparency about costs and resource consumption. For multicloud, sovereignty appears again, but in a sharper form: if the existing cloud provider has no local cloud region in a country, the common solution for compliance is another provider that has one. The other multicloud drivers are different in kind. Using the unique capabilities of each provider, so the business is not limited to the choices offered by a single cloud provider. Avoiding vendor lock-in. And resilience, which Google frames honestly: deploying on multiple clouds for disaster recovery or reliability might increase costs in the short term, but could prevent outages or failures. Read a scenario for which of these it states, and the reason the organization chose its architecture follows.

When the estate is meant to be temporary — and what it costs either way

Three temporary reasons, and the bill a permanent one runs up

Figure. Three cards for temporary hybrid or multicloud states — a short-term project, a multi-year transformation, and a corporate merger — above a band noting the costs Google names: management complexity, and the cost of building and operating across multiple clouds.

Worked example (synthetic). A firm plans a two-year hybrid phase while it modernizes. Asked what it should budget beyond service prices, the graded answer is the cost of operating across environments — Google's first-named challenge is management complexity.

Temporary estates have their own drivers, and Google names three. A short-term project: if the objective is a temporary state, a common driver is the need to reduce capital or general information technology spending for short-term projects. A long transformation: multi-year digital transformation projects that use a hybrid architecture for some time, so infrastructure and application modernization can align with business priorities. And a merger: the need to create a temporary hybrid, multicloud or mixed architecture after a corporate merger. The band underneath is the cost side, and it applies to permanent estates most of all. Google's first-named challenge of a multicloud strategy is increasing management complexity, and it tells you to account for the cost of building and operating a solution across multiple clouds, not only the cost of the services. That challenge is the bridge to the second objective, because it is exactly the problem a single control panel exists to solve.

One control panel for every environment

The guide says Anthos; Google now says GKE fleet management

  • Manage clusters on Google Cloud, other public clouds and on-premises
  • A fleet: clusters and resources grouped and managed together
  • One console for every fleet cluster, wherever it runs
  • GKE Enterprise features are now part of standard GKE

Worked example (synthetic). A bank runs clusters in its own data center, on Google Cloud and on a second cloud. Registered to one fleet, all three appear in one console — one team, one place to look.

The second objective describes Anthos as a single control panel for hybrid or multicloud infrastructure. Some of Google's own pages still use that name — the hybrid cloud page says Google offers Anthos, a consistent Kubernetes experience for applications across on-premises and multiple clouds. But the product has moved on. Google's Anthos pages now redirect to Google Kubernetes Engine, or GKE; its GKE Enterprise release-notes page archives the old Anthos releases, and states that the features that were part of GKE Enterprise have become part of the standard GKE offering, and that GKE is a single offering without editions or tiers. So on the exam, Anthos is the answer; in Google's documentation, the same capability is GKE fleet management. Google describes it as a set of capabilities that helps an organization manage clusters, infrastructure and workloads on Google Cloud and across public cloud and on-premises environments, built around the idea of the fleet: a logical grouping of Kubernetes clusters and other resources that can be managed together. And the single control panel is literal: the Google Cloud console provides a central user interface for managing all of your fleet clusters no matter where they are running.

The same idea under three names

What the exam calls it, and what Google calls it now

Where you meet itThe name usedWhat Google says now
The exam guideAnthos—
GKE release-notes archiveAnthos releases, then GKE EnterpriseAn archive of past updates
Google's current documentationGKE, with fleet managementGKE Enterprise features are part of standard GKE; GKE has no editions or tiers

Worked example (synthetic). An exam item asks which Google Cloud offering provides a single control panel across on-premises and other clouds. The graded answer is Anthos — the name the guide still uses — even though the documentation now files it under GKE.

This table exists so that the rename does not cost you a mark. The exam guide says Anthos, and on the exam that is the word to choose. Google's release-notes archive shows the lineage: the page is labelled as an archive of past updates to GKE Enterprise, and its oldest entries are Anthos releases — Anthos one point seven point one is now available, and so on. And Google's current documentation says the features that were part of GKE Enterprise have become part of the standard Google Kubernetes Engine offering, and that GKE is a single offering without different editions or tiers. One idea, three names. Learn the idea, answer the exam with its word, and read Google's documentation with the current one.

One fleet, clusters everywhere

Clusters register to the fleet; the console manages the fleet

Loading Diagram...
Figure 1 — Mermaid diagram

Figure: A flow chart in which GKE clusters on Google Cloud, Google Distributed Cloud clusters on-premises, GKE clusters on other public clouds and attached third-party Kubernetes clusters all register to one fleet — the ones outside Google Cloud through a Connect Agent. The fleet is managed from the Google Cloud console, and Config Sync applies configuration from a Git repository to the whole fleet.

Worked example (synthetic). A retailer's on-premises cluster sits behind a VPN. It still joins the fleet: the Connect Agent reaches Google through the VPN, so the cluster is managed from the same console as the rest.

Here is what the single control panel actually looks like. On the left are the environments Google lists for GKE: clusters on Google Cloud; Google Distributed Cloud, which is Google Kubernetes Engine, or GKE, run on-premises on VMware or bare metal; GKE on other public clouds; and attached clusters, which Google defines as third-party Kubernetes clusters registered to your fleet. Google states that a fleet can be made up entirely of GKE clusters on Google Cloud, or include clusters outside Google Cloud. For those outside clusters, a Connect Agent is installed to establish control plane connectivity with Google Cloud, and the agent can traverse network address translation, egress proxies, virtual private networks and other interconnects between your environments and Google. On the right, the fleet is managed from the Google Cloud console — Google even says you can manage your Kubernetes clusters on the other two big public clouds from it. And along the bottom, configuration comes from one Git repository, applied by Config Sync, which is where consistency comes from. The figure is a registration, not a network: a cluster on another cloud stays on that cloud.

The business value of one control panel

Each capability removes a specific kind of work

Without a single control panelWith a fleet
A production-wide change is made cluster by cluster, project by projectClusters are grouped and managed from one fleet host project
Each cluster's configuration drifts on its ownConfig Sync applies one Git source of truth and prevents configuration drift
Every new cluster is set up by handFleet-level defaults mean no configuring each cluster individually
Each environment has its own sign-inFleets support your existing third-party identity provider
Multicloud grows complex and time-consumingOne unified platform across environments

Worked example (synthetic). A bank must apply one security policy to forty clusters in three environments. The business value of the fleet is that the policy is set once, as a fleet default, instead of forty times.

The objective asks for business value, so this table states it as work that stops happening. Google's own example: without fleets, if you want to make a production-wide change to clusters, you need to make the change on the individual clusters, in multiple projects. With fleets, you group and normalize clusters and manage them from a single fleet host project. Configuration stops drifting: Config Sync uses a central source of truth like a Git repository to improve stability, consistency and security, and automatic syncing lets you manage fleets centrally and prevent configuration drift. New clusters stop needing hand setup: Google Kubernetes Engine, or GKE, can set fleet-level defaults for Cloud Service Mesh, Config Sync and Policy Controller, without having to configure each cluster individually. Sign-in stops fragmenting: fleets support your existing third-party identity provider. And the last row is the reason the guide calls this business value at all — Google's multicloud page warns that without a unified platform to manage your environments, things can quickly get very complex and time-consuming.

What this topic actually tests

Three discriminations, two objectives

Permanent or temporary? a merger or migration is a stage, not a strategy. Which driver is stated? sovereignty, capability, lock-in or resilience. Which name? Anthos on the exam; GKE fleet management in Google's documentation — one idea, managed from one console.

Close on three discriminations. First, permanent or temporary: Google separates an estate built to meet a lasting business objective from one that exists for a migration, a short project, a long transformation or a merger — and the scenario usually says which. Second, which driver the scenario states: sovereignty, which can point to hybrid or to a second provider with a local region; unique capabilities; avoiding lock-in; or resilience, which may cost more in the short term but could prevent outages. Third, the name. On the exam, the single control panel for hybrid and multicloud is Anthos. In Google's documentation it is fleet management in Google Kubernetes Engine, where clusters in every environment are grouped into a fleet and managed from one console. Both names describe one idea, and it is the idea the exam is really testing.

Official sources for this topic

Ready to study Cloud Digital Leader (GCP-CDL)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free