Planning and configuring compute resources

Study guide for Associate Cloud Engineer, Unit 2 · Topic 1. 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, quoted. Planning and configuring compute resources. Considerations include:

1. Selecting appropriate compute choices for a given workload (e.g., Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions)
2. Using Spot VM instances and custom machine types as appropriate

Planning and configuring compute resources

Where the workload runs, and what it runs on

Which platform? Compute Engine, Google Kubernetes Engine, Cloud Run or Cloud Run functions — read from what the workload needs. Which machine? A Spot VM when interruption is acceptable, a custom machine type when no predefined shape fits.

This is the Associate Cloud Engineer's first planning topic, and the guide frames it as considerations rather than products. It has two objectives. The first is selecting the right compute choice for a given workload — Compute Engine, Google Kubernetes Engine, Cloud Run or Cloud Functions. The second is using Spot virtual machine (VM) instances and custom machine types as appropriate. The Cloud Digital Leader exam asked what each platform is worth to a business; this exam asks the engineer's question, which is what the workload requires and what that rules out. So every slide here ends in a decision, and where the decision is carried by a command-line flag, you will see the exact flag Google documents.

Four platforms, one question: what does the workload need?

From self-managed machines to code that only runs on an event

• Compute Engine: self-managed VMs and bare metal instances
• GKE: containers on Kubernetes clusters you configure and operate
• Cloud Run: containers run directly on Google Cloud infrastructure
• Cloud Run functions: code bound to an event or an HTTPS endpoint

Worked example (synthetic). A retailer has four workloads: a licensed ERP package, a stateful recommendation engine, a stateless storefront API, and a thumbnail resizer that fires on each upload. That is four answers — Compute Engine, GKE, Cloud Run, Cloud Run functions — not one.

The guide names four compute choices, and the fastest way to separate them is by what you have to manage. At one end is Compute Engine, which Google calls an infrastructure as a service product that offers self-managed virtual machine instances and bare metal instances, with operating systems for both Linux and Windows. You choose and run the operating system. In the middle are the two container platforms. Google puts it in one sentence: it offers two major platforms for running containerized applications — Google Kubernetes Engine, or GKE, for running containers on Kubernetes clusters, and Cloud Run for running containers directly on Google Cloud infrastructure. On GKE you still manage the Kubernetes clusters — node configuration, networking, scaling and upgrades. On Cloud Run, all you provide is source code or a container image. At the far end are functions. The guide says Cloud Functions, but that product has been renamed Cloud Run functions, and that is the name you will see in the console today. A function is code bound to an event — Google's examples include responding to Cloud Storage events when a file is created, changed or removed.

What each platform is best suited for

Read the workload's shape, then the column

Worked example (synthetic). An inventory service must keep data on an attached volume between restarts. "Stateful" moves it out of the Cloud Run column and into GKE's.

Google's own comparison supplies the middle two rows almost word for word. Google Kubernetes Engine supports both stateless and stateful applications and is ideal for complex applications with specific resource needs; Google adds that it is best suited for complex microservices architectures, stateful applications, workloads requiring custom infrastructure or network configurations, and scenarios where deep control over Kubernetes is essential. Cloud Run is best suited for stateless, request or event-driven services, web services and functions. The word that most often decides an exam item is the one in bold: stateless or stateful. Functions sit at the end because they are the narrowest shape — Google describes the automatic provisioning of an HTTPS endpoint as making functions a perfect candidate for webhooks. And Compute Engine sits at the start because it is the answer when the workload needs the machine itself: a self-managed virtual machine, its operating system, or a bare metal instance.

Google's test for a Cloud Run service

Meet every criterion, or look at GKE

Figure. Three criteria for a Cloud Run service: how it is invoked (requests, streams or events, or running to completion), where it keeps files (no local persistent file system), and how many copies (built for multiple simultaneous instances). A band beneath says an app meeting all three fits Cloud Run, and one missing any should look at GKE.

Worked example (synthetic). A legacy app writes its session state to local disk and assumes it is the only copy running. It fails two of the three criteria, so the planning answer is GKE, not Cloud Run.

Google publishes an explicit test for Cloud Run, and it is worth memorising as three questions, because the exam writes scenarios that fail exactly one of them. Google's wording is that to be a good fit as a Cloud Run service, your app needs to meet all of the following criteria. First, it serves requests, streams or events delivered using HTTP, HTTP/2, WebSockets or gRPC — or it executes to completion. Second, it does not require a local persistent file system, only a local ephemeral file system or a network file system. Third, it is built to handle multiple instances of the app running simultaneously. The page also sets a per-instance resource ceiling, which changes over time and is not shown here. If an app meets the criteria and runs to completion rather than serving, that is a Cloud Run job — Google says jobs are well-suited to code that performs work and quits when the work is done. And if an app does not meet all of the criteria, Google's own advice is to check out Google Kubernetes Engine as a hosting option.

The selection, as a sequence of questions

Stop at the first answer that fits

Figure: A decision flow. If the workload is code that runs when an event arrives, choose Cloud Run functions. Otherwise, if it is a container meeting all Cloud Run criteria, choose Cloud Run, as a service or as a job if it runs to completion. Otherwise, if it needs Kubernetes, stateful storage or custom network configuration, choose GKE, in Autopilot mode unless it needs Standard. Otherwise choose Compute Engine with a self-managed VM.

Worked example (synthetic). A nightly report generator is containerized and exits when done. It stops at the second question: a Cloud Run job.

Drawn as a sequence, the selection becomes a short walk from the most managed option to the least, and you stop at the first one that fits. Is it code that should run when an event arrives, such as a file landing in Cloud Storage? Then it is Cloud Run functions. If not, is it a container that meets all of the Cloud Run criteria? Then it is Cloud Run — a service if it serves requests, a job if it runs to completion. If not, does it need Kubernetes, stateful storage, or custom infrastructure or network configuration? Those are the cases Google names for Google Kubernetes Engine. And if the workload needs the machine itself — a self-managed virtual machine and its operating system — it is Compute Engine. The order matters because moving between the two container platforms is cheap: Google notes you can use the same image in either platform without any modifications, so starting on Cloud Run is not a trap if the workload later outgrows it.

Choosing GKE is two decisions: Autopilot or Standard

Google's default is Autopilot

Worked example (synthetic). A team needs a privileged container to load a kernel module on each node. That is outside Autopilot's constraints, so this workload goes on a Standard cluster.

Once Google Kubernetes Engine is the answer, the exam asks a second question: which mode of operation. Google marks Autopilot as recommended — a managed experience in which GKE handles most of your infrastructure for you so that you can focus on your applications. Standard mode hands that work back to you: you must plan the capacity of nodes in Standard node pools based on your workload requirements, and you manage resource allocation and the placement of Pods on specific nodes. Google's stated best practice decides most items: use Autopilot for most workloads, unless your application requires privileges or configuration options that don't meet the Autopilot constraints. So the exam signal for Standard is a requirement for control over nodes — privileged workloads, specific node configuration — and without that signal, Autopilot is the planning answer.

Spot VMs: cheaper capacity that can be taken back

For workloads that can be interrupted — and only those

• Fault-tolerant workloads: Spot can reduce Compute Engine costs significantly
• Compute Engine can preempt them at any time to reclaim capacity
• No live migration, no automatic restart, and no SLA
• Create with --provisioning-model=SPOT; Spot replaces preemptible VMs

Worked example (synthetic). A genomics lab runs thousands of independent alignment tasks overnight. A preempted VM only slows the run, so Spot fits. Its public results portal, which customers expect to be up, stays on standard VMs.

The second objective starts with Spot virtual machine instances. The trade is stated plainly by Google: if your workloads are fault-tolerant and can withstand possible VM preemption, Spot VMs can reduce your Compute Engine costs significantly — and batch processing jobs are Google's example. The price of that saving is that Compute Engine can preempt a Spot VM at any time. Google lists what else you give up: Spot VMs can't live migrate to become standard VMs while running, and can't be set to automatically restart on a host event, and because of those limitations they are not covered by any service level agreement, or SLA, and are excluded from the Compute Engine SLA. They are also finite capacity, so they might not always be available. Configuration is one flag: to create Spot VMs, you must include the provisioning model flag set to SPOT. And if the exam says preemptible, treat it as the older name — Google says Spot VMs are the latest version of preemptible VMs, and recommends Spot instead. The difference you may be tested on is runtime: preemptible VMs can only run for up to twenty-four hours at a time, and Spot VMs have no maximum unless you set one.

What happens when a Spot VM is preempted

The termination action decides the end state

Figure: A flow: Compute Engine preempts the Spot VM, a best-effort shutdown period of up to 30 seconds follows, and the instance termination action decides the end state. With STOP or no action set the VM is stopped and its state is TERMINATED; with DELETE the VM is deleted.

Worked example (synthetic). A batch worker writes its checkpoint in a shutdown script, and the fleet uses DELETE so preempted workers do not pile up as stopped VMs.

What happens at preemption is a common exam item, and it turns on one setting. At preemption time, Google says, Compute Engine either stops — the default — or deletes your Spot virtual machines (VMs), depending on the termination action you specify for each one. You set it at creation: Google says you can optionally specify a termination action by including the instance termination action flag. Before either happens there is a shutdown period, and Google warns that for Spot VMs it is best effort and up to thirty seconds, shorter than for other instances — so a shutdown script must be quick. Then the end state follows from the action: if it is STOP or not specified, Compute Engine stops the VM, transitioning it to a TERMINATED state; if it is DELETE, Compute Engine deletes the VM. The planning question is what you want left behind: a stopped VM you can start again, or nothing.

Custom machine types: when no predefined shape fits

Choose the vCPU count and memory yourself

• Predefined machine types have a preset vCPU count and memory
• Custom: for workloads that fit no predefined type, or need a bit more
• Match vCPUs to per-CPU software licenses
• gcloud: --custom-cpu, --custom-memory, --custom-vm-type, --custom-extensions

Worked example (synthetic). A database licensed per CPU needs 6 vCPUs and more memory than the matching predefined type offers. A custom N2 machine type with extended memory matches the license and the workload without paying for the next size up.

The other half of the second objective is custom machine types. Google's baseline is that a predefined machine type has a preset number of virtual CPUs and amount of memory. When none fits, Compute Engine lets you create a custom machine type with customized CPU and memory resources for some of the machine series. Google names three scenarios where custom machine types are ideal: workloads that aren't a good fit for the predefined types; workloads that require more processing power or more memory but don't need all the upgrades of the next level machine type; and workloads with per-CPU software license costs, where you customize the number of virtual CPUs to avoid license costs for unused processing power or to match available license counts. Two constraints matter for planning. Custom types are available only for some families — in the general-purpose family, only the N and E machine series. And if a workload needs more memory per CPU than the default range, extended memory is available on some custom types, such as N2 and N4. On the command line, alongside naming the custom type in the machine type, Google documents the custom options: custom CPU (central processing unit), custom memory, custom virtual machine (VM) type, and custom extensions.

Where a custom type sits among the machine families

Family, then series, then type — custom only in some series

Worked example (synthetic). A team wants a custom shape on a compute-optimized machine for a simulation. The family does not offer one, so the choice is the nearest predefined compute-optimized type — or a custom N-series type if the workload does not need compute-optimized performance.

Custom machine types only make sense inside Compute Engine's naming structure. Google organizes machines into families, and each machine family is further organized into machine series and predefined machine types within each series — for example, within the N2 series in the general-purpose family, you can select the n2-standard-4 machine type. The families describe what the hardware is for. General-purpose gives the best price-performance ratio for a variety of workloads. Compute-optimized is designed for high performance computing solutions and compute-intensive workloads. Memory-optimized is ideal for memory-intensive workloads, offering more memory per core than other machine families. Accelerator-optimized is ideal for massively parallel workloads such as machine learning. Custom types sit in only a corner of that grid: the general-purpose N and E series, and the G2 series in the accelerator-optimized family. So a scenario that asks for a custom shape on another family has a trap in it — the answer is either the nearest predefined type in that family, or a custom general-purpose type if the workload does not really need the specialised hardware.

What this topic actually tests

Four decisions, two objectives

Stateless or stateful? Cloud Run, or GKE. Autopilot or Standard? Autopilot unless the workload needs node-level control. Can it be interrupted? Then Spot, with a termination action. Does any predefined shape fit? If not, a custom type — in the N or E series.

Close on the four decisions the exam turns into scenarios. First, stateless or stateful: a stateless, request-driven container that meets all the Cloud Run criteria belongs on Cloud Run, and a stateful or deeply customised one belongs on Google Kubernetes Engine. Second, once on GKE, Autopilot or Standard: Google's best practice is Autopilot for most workloads, unless the application needs privileges or configuration Autopilot does not allow. Third, can the workload be interrupted: if it is fault-tolerant, Spot virtual machines (VMs) cut the cost significantly, created with the SPOT provisioning model, and the termination action decides whether a preempted VM is stopped or deleted — but never for something that needs a service level agreement (SLA). Fourth, does any predefined machine type fit: if not, a custom machine type, remembering that in the general-purpose family only the N and E series offer one. The next topic plans storage the same way.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 2
• Compute Engine overview
• GKE and Cloud Run
• Deploy functions to Cloud Run
• Spot VMs — Compute Engine
• Create and use Spot VMs
• Preemptible VM instances — Compute Engine
• Is my app a good fit for Cloud Run?
• What is Cloud Run
• Choose a GKE mode of operation
• Create a VM with a custom machine type
• Machine families resource and comparison guide