The case
The project was ready. Only the server choice was missing.
With the projects organized, Isaac opened the screen to create the store's first VM and found dozens of machine types, several disk types and a list of operating systems.
Choosing too big was waste. Choosing too small would bring the store down on Black Friday.
This post builds on Virtual Machines, Cloud Service Models and Google Cloud.
The problem
A VM sized to fit
Each workload calls for a different mix of processor, memory, disk and network. A VM with too many resources wastes money, and one with too few gets stuck at the peak.
And a single VM is a single point of failure: if it goes down, the store goes down with it.
The solution
Compute Engine
Compute Engine is Google Cloud's VM service. It is IaaS, as we saw in Cloud Service Models: Google takes care of the hardware and the virtualization, and you take care of the operating system and everything above it. The VMs live in a project, in a zone within a region, attached to a VPC network.
When you create a VM, you choose four things:
Zone
Where the VM runs, inside a region. Close to the customers, to reduce latency.
At the store: São Paulo, southamerica-east1.
Machine type
How many processors (vCPUs) and how much memory the VM has.
At the store: enough for the peak, without much to spare.
Image
The operating system and starting software of the VM, such as a version of Linux or Windows.
At the store: a Linux image with the order system installed.
Disk
Where the operating system and the data live. There are several types, which we'll see next.
At the store: a disk that survives if the VM is deleted.
Billing is per second, with a one-minute minimum. If the VM is turned off, you stop paying for the processor and the memory, but the disk keeps being charged.
A feature of Google's own is live migration: when Google does maintenance on the physical server, the running VM is moved to another one without being restarted.
Machine types
Machine families
Machine types are grouped into families, each designed for a workload profile:
| Family | What it's for | At the store |
|---|---|---|
| General-purpose | Balance between processor and memory, the starting point for most workloads | The website and the order system |
| Compute-optimized | The highest performance per core, for heavy computation | Freight calculation in batches |
| Memory-optimized | Lots of memory per core, for data that fits in RAM | An in-memory database |
| Storage-optimized | Lots of local disk, with fast reads and writes | A database with heavy writes |
| Accelerator-optimized | GPUs and other accelerators, for machine learning | Product recommendations |
In some series, instead of a ready-made size, you assemble a custom machine type: you choose the number of vCPUs and the amount of memory the workload needs, and you pay only for that.
Data
Disks and images
The VM starts from an image: a template with the operating system. Google offers public images, and you can create custom images with your own software already installed, to create identical VMs in minutes.
The data lives on disks, like the ones described in Cloud Storage. Compute Engine has three options:
- Persistent Disk: a network-attached, replicated and durable disk. It is the classic VM disk, widely used as the boot disk.
- Hyperdisk: a network-attached disk, also durable, with more performance and size, and with adjustable speed.
- Local SSD: a disk physically attached to the server. It is the fastest, but the data is lost if the VM is stopped.
A copy of the disk at a point in time is a snapshot, the way to make a backup.
Don't mix them up
Persistent Disk × Local SSD
Persistent Disk and Hyperdisk
“Does the data need to survive the VM?”
- Example
- The store's order database.
- Focus
- Durable: the data stays even if the VM is stopped or deleted.
Local SSD
“Do I need the fastest reads and writes, and is the data disposable?”
- Example
- A temporary cache, which the store recreates when it needs to.
- Focus
- Very fast, but loses the data when the VM is stopped.
Scale
Scale and availability
To avoid depending on a single VM, you create an instance template, which holds the recipe for the VM: machine type, image and disk. With it, you form a managed instance group (MIG), which looks after several identical VMs as if they were one.
The group offers:
- Autoscaling: adds VMs when demand rises and removes them when it falls. It is the elasticity from Cloud Fundamentals in practice.
- Autohealing: a health check tests each VM, and one that fails is recreated automatically.
- Zone distribution: a regional group spreads the VMs across several zones, so the failure of one zone doesn't bring everything down.
- Rolling update: replaces the VMs with a new version of the template, gradually.
Pricing
How to pay for the VM
The pricing models from Cloud Costs have their own names in Compute Engine:
| Model | In Compute Engine | When to use |
|---|---|---|
| On-demand | Standard price, billed per second | Unpredictable workload |
| Sustained use | Automatic discount for VMs that stay on for much of the month, on some machine types | Workload that runs a lot, without planning |
| Committed use | Committed Use Discounts, for 1 or 3 years | Constant and predictable workload |
| Spare capacity (spot) | Spot VMs, with a discount of up to about 90%, which Google can interrupt | Workload that tolerates interruption |
The sustained use discount is a standout feature of Google Cloud: it is automatic, with no commitment and no contract.
Key terms
Six terms to remember
Tap a card to see the definition.
Quick test
Three questions, exam style
01
A workload needs a lot of memory per core, like a database that keeps its data in RAM. Which machine family should you choose?
02
A VM in a managed group fails the health check. What does the group do?
03
The data of a VM needs to survive if it is stopped or deleted. Where should it be kept?
On the exam, Compute Engine is the answer when the workload needs a VM with control over the operating system. What changes from one question to another is the detail: the family by workload profile, the disk by durability, the managed group to grow and recover, and the pricing model by predictability. For Isaac, the next step is to run the store without managing VMs.