4.2 Computing in the Cloud
Key Takeaways
- Core cloud compute terms include virtual machines (VMs), containerization, containers, microservices, serverless computing, preemptible VMs, Kubernetes, autoscaling, and load balancing.
- Running compute in the cloud delivers elasticity, pay-per-use billing, global reach, reduced CapEx, faster provisioning, and no hardware maintenance.
- The compute-options continuum trades control for management overhead: VMs offer the most control, containers balance portability and management, and serverless offers the least management overhead.
- Compute Engine (IaaS) runs VMs on Google's infrastructure with machine types, preemptible/Spot VMs for up to ~60–80% discounts, sustained-use discounts for long-running work, and committed-use discounts for 1–3 year commitments.
- Rehost (lift and shift) is the natural first step for specialized legacy apps with vendor-supported binaries, undocumented dependencies, or specialized OS/runtime requirements that cannot be safely modified.
Computing in the Cloud: Core Terms
Quick Answer: Cloud computing delivers compute capacity—VMs, containers, microservices, and serverless functions—as an on-demand service. You pay for what you use, scale elastically, and let the provider operate the underlying hardware.
| Term | Definition |
|---|---|
| Virtual machine (VM) | A virtualized computer running an operating system (OS) on shared physical hardware, provisioned on demand. |
| Containerization | Packaging an application and its dependencies into a portable, lightweight unit that runs consistently across environments. |
| Containers | The runnable artifacts produced by containerization; many share one OS kernel, making them denser than VMs. |
| Microservices | An architectural style where an application is built as small, independently deployable services, each owning its own data. |
| Serverless computing | A model where the provider manages servers entirely; you upload code and it runs in response to events or HTTP requests. |
| Preemptible / Spot VMs | Short-lived, heavily discounted VMs that Google can reclaim with 30 seconds' notice; ideal for fault-tolerant batch work. Spot VMs are the current generation and the term the updated exam guide uses; "preemptible VM" is the legacy name for the same idea, with the difference that Spot VMs have no fixed 24-hour lifetime cap. |
| Kubernetes | An open-source orchestrator that schedules, scales, and manages containerized workloads across a cluster. |
| Autoscaling | Automatically adding or removing compute instances to match demand. |
| Load balancing | Distributing incoming traffic across multiple instances so no single instance is overloaded. |
These terms are not interchangeable: a VM virtualizes hardware, a container virtualizes the application runtime, a microservice is an architectural unit that may be packaged as one or more containers, and serverless is a deployment model where the provider manages the runtime entirely. Kubernetes and autoscaling are mechanisms that operate across many containers or VMs; load balancing sits in front of them to spread traffic.
Benefits of Running Compute in the Cloud
- Elasticity — Scale out for peaks and scale in for quiet periods, automatically.
- Pay-per-use — Pay for compute seconds, not for idle rack servers.
- Global reach — Deploy in Google's regions worldwide to serve users with low latency.
- Reduced CapEx — No upfront hardware purchases or data-center build-outs; spending shifts to operating expense.
- Faster provisioning — A VM is ready in seconds; a Kubernetes cluster in minutes; a function deploy in a single command.
- No hardware maintenance — Google handles failures, patches, and refreshes; teams spend time on the application, not the rack.
These benefits translate directly into business value: faster time-to-market, lower fixed cost, and the ability to enter new geographies without standing up physical data centers.
Compute Options: VMs vs Containers vs Serverless
| Dimension | VMs (Compute Engine) | Containers (GKE / Cloud Run) | Serverless (Cloud Functions / App Engine) |
|---|---|---|---|
| Control | Highest—full OS access | Medium—container runtime | Lowest—code only |
| Management overhead | High—patch OS, plan capacity | Medium—orchestration handled | None—provider manages everything |
| Scalability | Manual or autoscaler groups | Fast, container-level | Automatic, scale-to-zero |
| Best use case | Specialized/legacy apps needing OS-level control | Microservices, portable workloads | Event-driven, single-purpose code |
The guiding principle is simple: choose the abstraction with the least management overhead that still meets your needs. If your app needs OS-level control or a vendor-supported runtime, use VMs. If you can package the app as a container, use containers. If you can express the work as event-driven code, go serverless. Moving up this continuum—VM → container → serverless—is itself a modernization journey for a single workload.
Compute Engine: Business Value
Compute Engine is Google Cloud's Infrastructure-as-a-Service (IaaS) offering: you create and run VMs on Google's global infrastructure. It is the foundation for lift-and-shift migrations and for any workload that needs full OS-level control.
Key capabilities and cost levers:
- Machine types — Predefined and custom VM shapes tuned for general-purpose, memory-optimized, compute-optimized, or GPU/TPU-accelerated workloads.
- Preemptible and Spot VMs — Up to ~60–80% discount for batch and fault-tolerant jobs that can be interrupted with 30 seconds' notice.
- Sustained-use discounts — Automatic price reductions for VMs that run long portions of the month, with no commitment required.
- Committed-use discounts — Up to ~57% off in exchange for a 1- or 3-year resource commitment.
- Live migration — VMs stay running during host maintenance, so routine events don't require self-built high-availability tricks.
When to choose Compute Engine: lift-and-shift migrations; specialized OS or runtime requirements; batch and high-performance computing (HPC) workloads using preemptible VMs; monolithic apps that aren't ready to be decomposed; and workloads needing GPU/TPU accelerators with full OS control.
Why Rehost Fits Specialized Legacy Applications
Some applications are hard to refactor: they have undocumented dependencies, vendor-supported binaries you cannot modify, or specialized OS/runtime requirements (mainframe emulators, custom kernel modules, licensing tied to a MAC address). Rehost (lift and shift) preserves the existing OS and runtime exactly, moving the VM image to Compute Engine with minimal change. You get infrastructure cost savings immediately, and the app runs on Google's reliable, globally distributed fabric while a later replatform or refactor phase is planned.
Exam trap: Rehost is not "no change forever"—it is the fastest way out of an aging data center. Most rehosted apps are candidates for replatforming or refactoring once they are stable in the cloud. Treat it as a starting point, not the end state.
A data-science team runs fault-tolerant batch jobs that can be restarted cheaply after interruption. Which Compute Engine pricing option gives them the largest discount?
Which statement best describes serverless computing on Google Cloud?
An organization wants to migrate a legacy application with undocumented dependencies and a vendor-supported binary they cannot modify. Which compute path is most appropriate first?
What is the primary advantage of containerization over running the same workload on VMs?