Computing in the cloud

Study guide for Cloud Digital Leader, Unit 4 · Topic 2. 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 options for and advantages of running compute workloads in the cloud.

Objectives, quoted from the exam guide:

1. Define the main cloud compute terms, including: virtual machines (VMs); containerization; containers; microservices; serverless computing; preemptible VMs; Kubernetes, autoscaling, load balancing.
2. Describe the benefits and business value of running compute workloads in the cloud.
3. Explain the choices and constraints between different compute options.
4. Discuss the business value of using Compute Engine to create and run virtual machines on Google’s infrastructure.
5. Discuss the business value of choosing a rehost migration path for specialized legacy applications.

Computing in the cloud

The words, the value, the choice, the default and the way in

The words — virtual machines, containers, microservices, serverless, Spot and preemptible VMs, Kubernetes, autoscaling, load balancing. The value of running compute in the cloud. The choice between compute options, and what each one costs you in control. The default — Compute Engine. The way in — rehosting a specialized legacy application.

This topic's summary in the guide is: discuss the options for and advantages of running compute workloads in the cloud. Its five objectives are easiest to hold as five words. The words themselves come first — the vocabulary every later compute question assumes, from virtual machines to load balancing. Then the value: what an organization actually gains by running its compute in the cloud rather than on hardware it owns. Then the choice, which is the heart of the topic: Google offers several places to run code, and each trades control for simplicity in a different proportion. Then the default: Compute Engine, the virtual machine service many migrations land on first. And finally the way in: the rehost path, which is how a specialized legacy application that cannot be rewritten still gets to the cloud. The exam asks most about the choice, so the deck spends the most time there.

Four ways to package and run code

Virtual machine, container, microservice, serverless

Worked example (synthetic). A retailer's checkout, catalogue and search are three microservices, each packaged as a container. Where those containers run — on VMs it manages, or on a serverless platform — is a separate decision.

The first objective is vocabulary, and four of its terms describe how code is packaged and run. A virtual machine, or VM, in Google's words, is a software-based computer that provides an isolated environment on host hardware; each guest VM runs on an isolated partition, completely separated from other guests. The trade is weight: that isolation means VMs tend to be larger and take up more resources. A container is lighter. Google defines containers as lightweight packages of your application code together with dependencies, such as specific versions of programming language runtimes and libraries. The difference in one line: containers virtualize at the operating system level, while VMs virtualize at the hardware level. Containerization is the practice of packaging software this way, and Google's case for it is a separation of responsibility — developers focus on application logic and dependencies, while information technology operations teams focus on deployment and management. Microservices is an architecture rather than a package: it allows a large application to be separated into smaller independent parts, each with its own realm of responsibility, in contrast to traditional monolithic applications built as a single, unified unit. And serverless computing is an execution model that allocates machine resources on an as-used basis, so developers build and run applications without having to manage any servers. Notice these are not four rungs of one ladder. Google calls containers a well-suited microservices architecture example, because they let you focus on developing the services without worrying about the dependencies — so a microservice can run in a container, and that container can run on a VM or on a serverless platform.

Five words for keeping it running

Kubernetes, autoscaling, load balancing, and two names for one discount

Figure. Four cards. Kubernetes: an open source system to deploy, scale and manage containerized applications, which self-heals. Autoscaling: adding or deleting VM instances with load. Load balancing: distributing user traffic across instances. Spot VMs, formerly preemptible VMs: excess capacity at a much lower price that Compute Engine may stop, suitable only for fault-tolerant work.

Worked example (synthetic). A nightly rendering job splits into a thousand independent tasks. If some Spot VMs are reclaimed, those tasks rerun and the job finishes later — which is exactly the fault tolerance Spot VMs require.

The remaining terms describe how running code is kept running. Kubernetes is, in Google's words, an open source system to deploy, scale and manage containerized applications anywhere; it automates operational tasks of container management, and monitors health to enable self-healing by restarting or replicating containers. Autoscaling is the ability to automatically add or delete virtual machine instances based on increases or decreases in load, and Google says it helps applications gracefully handle increases in traffic and reduce costs when the need for resources is lower. Load balancing is the partner of autoscaling: a load balancer distributes user traffic across multiple instances of your applications — so when autoscaling adds an instance, the load balancer is what sends it work. The last term needs a correction. The guide says preemptible VMs, and Google's own preemptible page now says Spot VMs are the latest version of preemptible VMs, and recommends using Spot VMs instead. Both are the same idea: Compute Engine might stop, or preempt, these instances if it needs to reclaim the capacity, and in exchange they cost much less. Google's condition is explicit — if your workloads are fault-tolerant and can withstand possible preemption, Spot VMs can reduce your Compute Engine costs significantly. One difference is worth knowing: preemptible VMs can only run for up to twenty-four hours at a time, while Spot VMs have no maximum runtime unless you set one.

What running compute in the cloud is worth

Capacity that follows demand, and less time spent keeping it alive

• Capacity follows load: add instances as traffic rises, remove them as it falls
• No paying for idle capacity on serverless platforms
• Automated self-healing and zone-spread deployment for availability
• Maintenance without interrupting the workload
• Fewer physical machines, and work that moves freely in containers

Worked example (synthetic). A tax-filing service is busy for six weeks a year. On owned servers it pays for the peak all year; in the cloud, capacity grows for the six weeks and shrinks back after.

The second objective asks for the benefits and business value of running compute in the cloud, and each benefit is worth tying to the mechanism that produces it. The first is capacity that follows demand. Autoscaling adds instances as load rises and removes them as it falls, which Google says lets applications gracefully handle increases in traffic and reduce costs when the need for resources is lower. Serverless platforms push that further: you don't pay for idle capacity, which Google says helps lower the operational costs associated with running and managing your own servers. The second is availability without a larger operations team. Managed instance groups offer automated services — autoscaling, autohealing, regional deployment across multiple zones, and automatic updating — to make workloads scalable and highly available. And Compute Engine's live migration lets Google perform maintenance without interrupting a workload or rebooting an instance. The third is consolidation: Google notes that multiple physical machines can be reconfigured as virtual machines running on a shared host, allowing organizations to reduce sprawl. The fourth is portability: container-based applications deploy easily and consistently whether the target is a private data center, the public cloud, or a developer's laptop. The thread through all four is that the organization stops buying for the peak and stops spending its engineers' time on keeping machines alive — which is the business value, not the technology.

Each benefit, and the mechanism behind it

A benefit with no mechanism is a slogan

Worked example (synthetic). An item offers "the cloud is always cheaper" as a benefit. The graded answer instead names a mechanism — capacity that shrinks when demand falls.

Read as a table, the benefits separate cleanly by the mechanism under each one. Paying less when demand is low comes from autoscaling removing instances as load falls, and from serverless platforms where you do not pay for idle capacity. Staying up through failures comes from managed instance groups, which autoheal and can be spread across multiple zones. Staying up through maintenance is a different mechanism: live migration moves a running virtual machine so Google can perform maintenance without interrupting the workload. Cheaper batch work comes from Spot VMs — excess Compute Engine capacity, which is why their availability varies, and why Google offers them only for work that can withstand being stopped. And moving work without rewriting it comes from containers, which deploy consistently wherever they land. The exam's distractors in this area are usually benefits without a mechanism, or a real mechanism attached to the wrong benefit — Spot VMs offered as the answer to availability, for instance, when Google says the opposite: Spot VMs are not covered by any service level agreement.

Four places to run code, and what each asks of you

More control always means more to manage

Worked example (synthetic). A retailer runs its stateful inventory service on GKE for fine-grained control, and its stateless storefront API on Cloud Run for simplicity. The same container images work on both.

The third objective is the choices and constraints between compute options, and one rule runs through all of them: the more control you take, the more you must manage. Compute Engine is the most control. Google calls it an infrastructure as a service product that offers self-managed virtual machine instances and bare metal instances — self-managed is the constraint. Google Kubernetes Engine, or GKE, is a managed implementation of Kubernetes, and Google says it is ideal if you need a platform that lets you configure the infrastructure running your containers, such as networking, scaling, hardware and security. It gives full control over the Kubernetes cluster, and it is best suited for complex microservices architectures, stateful applications and workloads needing custom infrastructure. GKE's Autopilot mode reduces what you manage: Google Cloud manages both the nodes and the control plane. Cloud Run is the other end. It is a fully managed application platform for running your code, function or container, and you don't have to create a cluster or manage infrastructure; with no incoming requests, even the last remaining instance is removed. The constraint is stated just as plainly: limited control over the underlying infrastructure — ideal for simplicity and speed — and best suited for stateless web services, APIs, batch jobs and event-driven apps. App Engine is a fully managed, serverless platform for web applications, but Google's own overview now says a newer and better alternative to App Engine is Cloud Run. The choices are not exclusive either: Google notes you can use the same container image on GKE or Cloud Run without modification.

Three questions that pick the option

Ask what the workload needs before naming a product

Figure: A decision flow. If the workload needs a whole machine rather than a container or plain code, choose Compute Engine. If it is containerized and stateless or event-driven, choose Cloud Run. If it is stateful or complex, choose GKE, or GKE in Autopilot mode when the team wants Google to manage the nodes and control plane.

Worked example (synthetic). An item describes a stateless image-resizing service triggered by uploads. The flow ends at Cloud Run on its second question.

Exam items on this objective describe a workload and ask where it should run, so it helps to ask the questions in a fixed order. First: does it need a whole machine, or is it code or a container? A workload that needs its own operating system and machine configuration points to Compute Engine. Second, for code and containers: is it stateless and request- or event-driven? Google says Cloud Run is best suited for exactly that — stateless web services, APIs, batch jobs and event-driven apps — with no cluster to create. Third, for what is left — stateful applications and complex microservices architectures — Google Kubernetes Engine, or GKE, is Google's answer, and the last question is how much of the cluster the team wants to run. Standard GKE gives full control over the cluster; Autopilot mode minimizes operational overhead because Google Cloud manages both the nodes and the control plane. The trap is answering with the most powerful option. More control is only a benefit when the workload needs it; otherwise it is work.

The business value of Compute Engine

Virtual machines on Google's infrastructure, shaped to the workload

• Run a wide range of workloads, from batch processing to web serving
• Predefined or custom machine types; Linux and Windows images
• Identical VMs in managed groups that autoscale and autoheal
• Live migration keeps VMs running through Google's maintenance
• Spot VMs for interruptible work at a much lower price

Worked example (synthetic). An engineering firm's simulation software needs a specific memory-to-processor ratio and a Windows image. Compute Engine can shape a custom machine type to fit, which no fully managed platform offers.

The fourth objective asks for the business value of using Compute Engine to create and run virtual machines on Google's infrastructure. The first value is range: Google says Compute Engine provides flexibility so that you can run a wide range of applications and workloads, and an instance can be either a virtual machine or a bare metal instance hosted on Google's infrastructure. The second is fit. Compute Engine provides many preconfigured public operating system images for both Linux and Windows, and if a preconfigured machine type doesn't meet your needs, you can create a custom machine type with customized processor and memory resources. The third is operations at scale. Managed instance groups let you operate applications on multiple identical virtual machines, with autoscaling, autohealing and deployment across multiple zones — and live migration lets Google perform maintenance without interrupting the workload or rebooting the instance. The fourth is cost choice: Spot VMs run fault-tolerant work on excess capacity at a much lower price. Hold one constraint beside all of that: Google calls Compute Engine self-managed infrastructure as a service. The machine's operating system and software are the customer's to run, which is the price of the control.

Compute Engine at scale

One entry point, a group of identical VMs, and the data behind them

Figure. Users send requests to Cloud Load Balancing, which distributes them across two identical Compute Engine virtual machines in different zones, inside a managed instance group. The virtual machines read and write application data. The callout says the group adds, deletes and recreates virtual machines while the load balancer spreads traffic across whatever is there.

Worked example (synthetic). One VM in the group freezes at midnight. Autohealing recreates it, and the load balancer sends traffic only to healthy VMs in the meantime — nobody is paged.

This is how Compute Engine is usually run in production, and each box does a different job. On the left, Cloud Load Balancing — a fully distributed, software-defined, managed service — is the single entry point, and a load balancer distributes user traffic across multiple instances of your application. In the middle is a managed instance group: multiple identical virtual machines, here in two zones. The group is what changes shape. Autoscaling adds virtual machines when load rises and deletes them when it falls; autohealing recreates a virtual machine that fails its health check; and a regional group spreads the machines across multiple zones so one zone failing does not stop the service. On the right is the data the machines read and write, which does not scale with them. The point of drawing it is the division of labour: the load balancer never creates a machine, and the group never routes a request. An exam item that asks which component keeps the application available when traffic doubles is asking about the group; one that asks how users reach whichever machines exist is asking about the load balancer.

Rehosting a specialized legacy application

Move it as it is, when changing it is not an option

• Rehost: move a workload with minor or no modifications
• Forced when the code cannot be changed and the workload cannot be retired
• Fastest path; the team keeps its tools and skills
• The cost: a rehosted workload is not optimized for the cloud
• VMware estates can move to Google Cloud VMware Engine unchanged

Worked example (synthetic). A manufacturer's scheduling system was built by a vendor that no longer exists; nobody can rebuild it. Rehosting it onto Compute Engine gets it out of an ageing data center without touching the code.

The fifth objective asks for the business value of choosing a rehost migration path for specialized legacy applications. Google defines rehost, also called lift and shift, as moving workloads from a source environment to a target environment with minor or no modifications or refactoring. For legacy applications it is often not a choice at all. Google says that if you cannot refactor a workload and cannot decommission it, you must use a rehost migration — for example, when it is difficult or impossible to modify the source code, or the build process cannot produce new artifacts. The value follows from how little changes. Rehost migrations are the easiest to perform because your team keeps using the same set of tools and skills, and they tend to be the quickest, compared with refactor or rebuild migrations. The honest cost is stated just as plainly: after a rehost migration, the workloads aren't optimized for the cloud. That is why rehost is often a first step, not a destination. Two landing places matter for this exam. Compute Engine takes a legacy application as a virtual machine. And Google Cloud VMware Engine is a fully managed service that lets you run the VMware platform in Google Cloud, helping you retain operational continuity with existing VMware environments. Google's Bare Metal Solution was once a third answer, but Google now says its availability is transitioning to a specialized, allowlist-only model, so do not reach for it by default.

Rehost against its neighbours

How much changes, and what that buys

Worked example (synthetic). An item describes a legacy application whose source code is lost and asks for the migration path. Replatform and refactor both require changing it, so rehost is the only answer that fits.

Rehost is easiest to understand beside the two paths the exam most often offers against it. A rehost moves the workload with minor or no modifications, and Google says it is ideal when a workload can operate as-is in the target environment, or when there is little or no business need for change. A replatform migration lifts the existing workloads and then optimizes them for the new cloud environment — for example, to use containers — and Google notes it takes more work than a rehost. A refactor migration modifies the workloads to take advantage of cloud capabilities, not just to make them work in the new environment, and it takes longer and needs new skills. Read down the second column and the rule for legacy applications appears on its own: every path except rehost requires changing the workload. When the scenario says the code cannot be changed, the choice is already made. When it says the business wants cloud-native benefits, rehost is the wrong answer, however quick it is.

What this topic actually tests

Four discriminations, five objectives

Package or platform? a container is how code travels; Cloud Run or GKE is where it runs. Control or simplicity? more control is more to manage. Group or load balancer? one changes the machines, the other routes to them. Can it change? if not, rehost — and accept it is not yet optimized.

Close on the four discriminations the exam leans on. First, package against platform: a virtual machine, a container and a microservice describe how code is packaged and divided, while Compute Engine, Google Kubernetes Engine (GKE) and Cloud Run are where it runs, and the same container can run on more than one of them. Second, control against simplicity: Compute Engine is self-managed, GKE gives full control of the cluster, and Cloud Run gives limited control in exchange for simplicity and speed — choose the least control the workload actually needs. Third, the managed instance group against the load balancer: the group adds, deletes and recreates machines, and the load balancer distributes traffic across whatever machines exist. And fourth, whether the workload can change: if it cannot, rehost is the path, it is the quickest, and it leaves the workload not yet optimized for the cloud. The next topic, serverless computing, takes the simplicity end of this spectrum further.

Official sources for this topic

• Cloud Digital Leader exam guide — Section 4
• What is a virtual machine? — Google Cloud
• What are containers? — Google Cloud
• What is microservices architecture? — Google Cloud
• What is serverless computing? — Google Cloud
• Autoscaling groups of instances — Compute Engine
• Instance groups — Compute Engine
• Live migration process — Compute Engine
• Compute Engine overview
• GKE overview
• GKE and Cloud Run
• What is Cloud Run
• An overview of App Engine
• Compute Engine instances
• Spot VMs — Compute Engine
• Migrate to Google Cloud: Get started
• Google Cloud VMware Engine overview
• Plan for Bare Metal Solution
• What is Kubernetes? — Google Cloud
• Cloud Load Balancing overview
• Preemptible VM instances — Compute Engine