Containers vs. Virtual Machines

What Are Containers and Virtual Machines?

Containers and virtual machines (VMs) are the two dominant ways to package and run application workloads in the cloud. They look similar at a distance — both let you run multiple isolated environments on a single physical server — but underneath, they use very different technology and have very different cost, performance, and operational profiles. The Cloud Digital Leader (CDL) exam expects you to articulate the difference clearly and map each model to the right Google Cloud product.

A virtual machine is a complete, simulated computer. It runs a full guest operating system (Linux, Windows, etc.) on top of a piece of software called a hypervisor, which carves up the physical server's CPU, RAM, and disk into isolated slices. On Google Cloud, the VM service is Compute Engine.

A container is a lightweight package that bundles only your application and its immediate dependencies — not a whole operating system. Multiple containers share the host kernel, which makes them start in seconds (sometimes milliseconds) and use far less memory than a comparable VM. On Google Cloud, containers run on Google Kubernetes Engine (GKE) for orchestrated workloads or Cloud Run for serverless workloads, with images stored in Artifact Registry.

For a CDL candidate, the question is rarely "what is a container, technically?" It is "when should our business use containers, and when do VMs still make sense?" This study note builds that decision framework, walks through the Docker → image → registry → runtime chain, introduces Kubernetes at a leader-friendly level, and explains Google Cloud's migration journey from VMs to containers to serverless.

Virtual Machines: The Foundation

A virtual machine is the original cloud abstraction. Before VMs, a physical server ran one operating system, full stop. If the workload only used 10% of the CPU, the other 90% sat idle. The hypervisor changed everything.

How the Hypervisor Works

A hypervisor is a thin software layer that sits between the physical hardware and one or more guest operating systems. It pretends to each guest OS that the guest has the whole machine to itself, while in reality the hypervisor schedules CPU cycles, allocates memory pages, and routes I/O between the guests and the real hardware. Google Cloud's hypervisor is a custom-hardened variant of KVM running on Google's data-center fleet.

Each VM on Compute Engine gets its own kernel, its own /proc filesystem, its own network stack, and its own block devices (Persistent Disk or Hyperdisk). When you boot a VM, you wait for the entire OS to come up — typically 30 to 90 seconds for a standard Linux image, longer for Windows Server.

What You Get With a VM

When you provision a Compute Engine VM, you pick:

• A machine family (E2, N2, N4 for general-purpose; C3 for compute-optimized; M3 for memory-optimized; A3 for accelerator-optimized with NVIDIA GPUs).
• A machine type that defines vCPU and RAM (e.g., e2-medium = 2 vCPU, 4 GB RAM).
• An OS image (Debian, Ubuntu, RHEL, Windows Server, COS, or your own custom image).
• A boot disk and optional additional disks.
• A VPC network and firewall configuration.

You then SSH in and treat the VM like any physical Linux or Windows server. You install your runtime, deploy your application, configure monitoring agents, and apply OS patches on your own schedule (or via OS Patch Management).

The Cost of Full Isolation

Strong isolation is the VM's biggest selling point and its biggest cost. Because every VM runs a full OS, you pay for:

• Memory overhead: The guest kernel, init system, system daemons, and package manager occupy 200 MB to 1 GB of RAM per VM before your application even starts.
• Disk overhead: Every VM image carries a full root filesystem — typically 2 to 20 GB.
• Boot time: Cold starts take 30+ seconds, which makes per-request scaling impractical.
• Patching workload: Every VM is its own server you must patch, monitor, and harden.

For workloads that run continuously and need strong isolation — databases, license-locked enterprise software, GPU training jobs — these costs are completely acceptable. For workloads that need to scale quickly or pack densely onto a few machines, they become a bottleneck.

Containers: The Modern Packaging Unit

A container is a process — or a small group of processes — running on the host OS, isolated from other processes by Linux kernel features like namespaces (for filesystem, network, and process visibility) and cgroups (for CPU and memory limits). Crucially, all containers on a single host share the same kernel.

Container Images and the Docker Workflow

You don't ship a container, you ship a container image. An image is a read-only, layered filesystem snapshot containing your application binary, its libraries, and a minimal user-space (often based on Alpine, Debian-slim, or Google's Distroless base images). The dominant tool for building images is Docker, though alternatives like Buildpacks, Kaniko, and ko all produce the same OCI-compliant image format.

The end-to-end workflow looks like this:

1. Write a Dockerfile describing your base image, dependencies, and entrypoint (the CDL exam does not require you to write Dockerfile syntax — just recognize the concept).
2. Build the image using docker build or Cloud Build.
3. Push the image to a container registry. On Google Cloud, this is Artifact Registry, which replaced the older Container Registry product in 2023.
4. Pull and run the image on a host that has a container runtime — containerd, Docker Engine, or a managed service like GKE or Cloud Run.

The Image Is Immutable

A container image is an immutable artifact. The same image you tested in dev runs byte-for-byte the same in staging and production. This eliminates the "works on my machine" class of bugs and underpins modern CI/CD pipelines.

Containers vs VMs at a Glance

白話文解釋（Plain English Explanation）

The technical contrast between containers and VMs becomes much easier to remember when you ground it in everyday Taiwanese scenarios. The three analogies below each illustrate the same core idea — sharing the underlying foundation lets you go faster and denser — but each highlights a different facet of the decision.

Analogy 1 — Apartment Building vs Hotel Rooms

Think about two ways to house 50 people in central Taipei.

Renting 50 individual apartments (virtual machines on Compute Engine) means each tenant gets their own kitchen, their own water heater, their own electricity meter, their own front door. The isolation is excellent — what happens in one apartment cannot affect another. But the building has to provide 50 kitchens, 50 water heaters, and 50 separate plumbing runs. Construction is expensive, maintenance is expensive, and moving in takes a week because each apartment must be fully furnished. This is exactly what running 50 VMs on Compute Engine looks like — every VM gets its own kernel, its own systemd, its own networking stack, its own disk. Strong isolation, high overhead.

Renting 50 hotel rooms (containers on GKE or Cloud Run) means all 50 tenants share the hotel's central kitchen, central laundry, central HVAC system, and central security desk. Each room still has its own bed, bathroom, and lock — that is the namespace isolation a container gets. But the heavy shared infrastructure is provided once by the building. New guests check in in five minutes, not five days. The hotel can fit 200 rooms in the same footprint as 50 apartments because the shared facilities don't multiply per guest. This is the container model: shared kernel, isolated processes, far higher density.

On Google Cloud, when you migrate ten Compute Engine VMs running a Node.js API to Cloud Run, you typically end up paying 30 to 70 percent less because you stop paying for ten redundant Linux installations. Artifact Registry stores the room-by-room "blueprints" (container images), Cloud Run is the hotel chain that books rooms on demand, and GKE is the higher-end hotel with concierge services (orchestration) for guests with complex needs.

Analogy 2 — Opening Your Own Restaurant vs Renting a Stall in a Food Court

You want to sell beef noodle soup to office workers in Xinyi District.

Opening your own standalone restaurant (a VM) means signing a 10-year commercial lease, getting your own gas line installed, hiring electricians, installing a grease trap, dealing with health inspectors, and decorating from scratch. The kitchen is yours — you can install a coal-fired oven, a 200-liter stock pot, anything you like. But the total setup cost easily reaches NT$3 million, and if business slows, you still pay rent on the whole space. This is what running a custom-OS application on Compute Engine feels like — you control the kernel, you can install custom drivers, you can run GPU workloads — but you pay for the whole VM whether it is busy or idle.

Renting a stall in a food court (a container on Cloud Run or GKE) means you walk into a building that already has the gas, the grease traps, the seating area, the dishwashing station, the cleaning crew, and the air conditioning. You bring your recipe, your signature ingredients, and your branding. You set up in two days, not two months, and you can move to a different food court in another district by simply re-printing your signage — the immutable container image is the equivalent of your recipe binder, portable across any compliant kitchen.

In Google Cloud terms, the "food court building" is the host VM that GKE or Cloud Run runs on, the "shared utilities" are the host kernel and the container runtime, and the "stalls" are your individual containers. GKE Autopilot is a premium food court where the management decides how many stalls to open and when, optimizing for foot traffic. Cloud Run is an even more on-demand model — you only pay when customers are actually at your stall, scale-to-zero when the food court is closed.

Analogy 3 — Shipping Cargo: Wooden Crates vs Standard Intermodal Containers

Before 1956, cargo shipping was a nightmare. Every shipment used different-sized wooden crates, sacks, or barrels. Loading a ship took weeks because longshoremen hand-carried each piece. Goods got damaged, stolen, or lost. Moving freight from a truck to a ship to a train required completely unpacking and repacking at each step.

Then Malcolm McLean invented the standardized intermodal shipping container. Suddenly, every cargo unit was the same size — 20 or 40 feet long, stackable, lockable, and crucially, portable across trucks, trains, and ships without unpacking. A ship that took three weeks to load now loaded in a day. Global trade volumes exploded.

A software container is the same idea applied to applications. Before containers, deploying software was the wooden-crate era — every team had its own scripts, every server had its own slight configuration drift, "works on my machine" was a daily lament. Once Docker standardized the OCI image format, that same image could run on a developer laptop, a CI pipeline, a Compute Engine VM, a GKE cluster, or a Cloud Run service — all without modification.

Artifact Registry is the container "port terminal" — the secure place where stacks of standardized images wait to be loaded. Kubernetes (and GKE) is the port crane operator, deciding which container goes on which ship (node) and where to stack it. Cloud Run is the on-demand express courier that grabs one container, delivers it for a single trip, and returns it to storage when done. The portability story is the same as the shipping container revolution: once you standardize the unit, the entire logistics network gets faster.

The Docker → Image → Registry → Runtime Chain

For the CDL exam you do not need to write Dockerfiles, but you do need to recognize the four conceptual stages of how a container goes from source code to running workload on Google Cloud.

Stage 1 — Build

A developer writes a Dockerfile that describes the base OS layer, the application dependencies, and the startup command. Cloud Build (Google Cloud's managed CI service) reads this Dockerfile, builds the image, and tags it with a version. Cloud Build can build images directly from a GitHub or Cloud Source Repositories trigger, with no developer laptop involved.

Stage 2 — Push to Artifact Registry

The built image is pushed to Artifact Registry, Google Cloud's managed artifact storage service. Artifact Registry supports container images plus Maven, npm, Python, Go, and OS package formats — a single integrated repository for all software artifacts. Images are stored regionally or multi-regionally and protected by IAM policies, so only authorized service accounts can pull them.

Stage 3 — Vulnerability Scanning

Artifact Registry can automatically scan every pushed image for known CVEs (Common Vulnerabilities and Exposures) using Container Analysis. Results feed into Binary Authorization, which can block the deployment of any image that fails policy.

Stage 4 — Pull and Run

A compute target — a GKE node, a Cloud Run service, or a Compute Engine VM with the container-optimized OS — pulls the image from Artifact Registry and starts it. The image is cached locally so subsequent restarts are near-instant. On Cloud Run, this entire pull-and-start cycle typically takes one to three seconds.

Kubernetes and Orchestration

Running one container on one server is easy. Running 500 containers across 50 servers — with health checks, rolling upgrades, traffic routing, secret management, and automatic restarts when something dies — is hard. The system that solves that hard problem is Kubernetes, often shortened to K8s.

What Kubernetes Does

Kubernetes is a container orchestrator. Originally developed inside Google as the open-source successor to the internal Borg system, Kubernetes was donated to the Cloud Native Computing Foundation in 2015 and has become the de facto standard for running containers in production. At a conceptual level, Kubernetes:

• Schedules containers onto nodes (the underlying VMs) based on available CPU and memory.
• Restarts failed containers automatically.
• Performs rolling upgrades when you publish a new image version.
• Routes traffic to healthy containers and away from unhealthy ones.
• Scales the number of containers up or down based on demand.
• Manages configuration and secrets injected into containers at runtime.

Pods, Deployments, and Services — at a CDL Level

You will not write Kubernetes manifests for the CDL exam, but you should recognize three key terms:

• A Pod is the smallest deployable unit — one or more tightly-coupled containers that share a network address and storage. Most pods contain a single container.
• A Deployment declares "I want N replicas of this pod, running this image version, upgraded with this strategy." Kubernetes makes reality match the declaration.
• A Service is a stable network endpoint that load-balances traffic across the pods of a deployment. Pods come and go; the service IP and DNS name stay constant.

GKE and GKE Autopilot

Google Kubernetes Engine (GKE) is Google Cloud's managed Kubernetes service. There are two operating modes:

• GKE Standard: You manage the node pools — the worker VMs that run the pods. You choose machine types, set autoscaling policies, and handle node upgrades (Google still handles the control plane).
• GKE Autopilot: Google manages the nodes for you. You only specify the workloads, and Google decides what VMs to provision and how big to make them. Billing is per pod-second of requested vCPU and memory, removing the cost of idle nodes.

For new Kubernetes workloads, GKE Autopilot is the recommended default because it removes most of the operational burden while preserving full Kubernetes API compatibility.

Cloud Run: Serverless Containers

Cloud Run is Google Cloud's serverless container platform. You build a Docker image, push it to Artifact Registry, point Cloud Run at it, and you get an HTTPS endpoint that scales from zero to thousands of instances in seconds. Cloud Run handles TLS termination, load balancing, autoscaling, traffic splitting, and per-100ms billing — you write zero infrastructure code.

Why Cloud Run Matters

Cloud Run sits at the intersection of three powerful properties:

• Container portability: Anything you can package in an OCI image runs on Cloud Run — Python, Node.js, Go, Java, .NET 6+, Rust, even custom C binaries.
• Serverless economics: No nodes to manage, scale-to-zero billing, per-request pricing. A Cloud Run service that gets zero traffic for a week costs zero dollars for that week.
• Operational simplicity: No clusters, no node pools, no networking plumbing. Deploy and forget.

Cloud Run Services vs Jobs

• Cloud Run services handle HTTP, gRPC, and WebSocket traffic — typical APIs, web apps, and webhook receivers.
• Cloud Run jobs execute a container to completion for batch work (nightly data exports, ETL runs, scheduled reports). They do not listen on a port.

When VMs Still Win

Containers are not always the right answer. CDL questions sometimes describe scenarios where Compute Engine VMs remain the best choice, and recognizing those scenarios scores easy points.

Scenario 1 — Legacy Applications That Cannot Be Containerized

Some enterprise applications expect a specific Windows Server build, install kernel-mode drivers, or use system services that assume a complete OS. Containerizing them is technically possible but rarely economical. Lift-and-shift them to Compute Engine with Migrate to Virtual Machines (M2VM) and modernize incrementally.

Scenario 2 — GPU Drivers and Specialized Hardware

GPU-bound workloads (AI training, scientific simulation, 3D rendering) typically need direct access to NVIDIA drivers, CUDA, or vendor-specific kernel modules. Compute Engine A2/A3/G2 machine families with NVIDIA T4, L4, A100, or H100 GPUs are the standard choice. While GKE supports GPU nodes, the bare-metal VM path is simpler for many ML teams.

Scenario 3 — License-Locked Software

Enterprise software vendors often license per VM, per socket, or against specific OS versions. A traditional VM model satisfies these license constraints cleanly; a container model can be ambiguous or unsupported.

Scenario 4 — Strong Isolation for Compliance

A handful of compliance regimes mandate hardware-level isolation — for example, certain government workloads or financial-industry secure enclaves. Hypervisor isolation on Compute Engine, optionally combined with Confidential VMs (AMD SEV / Intel TDX hardware encryption), exceeds the isolation that shared-kernel containers provide.

Scenario 5 — Custom Kernel or Networking

Workloads that need custom kernel modules, raw socket access, or specific Linux kernel features that the host does not expose to containers will run more reliably on a dedicated VM where you control the kernel build.

The Lift-and-Shift Then Modernize Migration Pattern

Most enterprises do not jump straight from on-prem to serverless containers. The proven Google Cloud path is a three-stage modernization journey.

Stage 1 — Lift-and-Shift to Compute Engine (Migrate to Virtual Machines)

Move existing on-prem VMs as-is to Compute Engine using Migrate to Virtual Machines (M2VM), formerly Migrate for Compute Engine. The application code does not change; the workload simply runs on Google's hardware instead of the on-prem rack. Migration is fast (often days to weeks), and you immediately gain elasticity, global networking, and Cloud Monitoring observability.

Stage 2 — Containerize with Migrate to Containers

Once workloads are on Google Cloud, Migrate to Containers (M2C) analyzes selected VMs, extracts the application binary plus its dependencies, and emits a container image with Kubernetes manifests. The output runs on GKE or Cloud Run, dramatically reducing the OS-patching surface area.

Stage 3 — Refactor Toward Serverless

After the application runs in containers, teams typically split monoliths into smaller services, replace stateful glue code with Pub/Sub and Cloud Functions, and move stateless HTTP services to Cloud Run. The end state often retains some VMs for legacy components but moves the bulk of new functionality to serverless containers.

How Containers Integrate With the Rest of Google Cloud

Container workloads on GKE or Cloud Run plug directly into the wider Google Cloud platform:

• Networking: Cloud Run services and GKE workloads can sit behind Cloud Load Balancing, get global anycast IPs via Cloud CDN, and route requests using API Gateway or Apigee.
• Identity: IAM governs who can deploy containers, and Workload Identity lets each container assume a Google service account to access Cloud Storage, BigQuery, Spanner, and more without managing static keys.
• Data: Containers commonly write to Cloud SQL, Firestore, Spanner, BigQuery, or Cloud Storage — see /en/certs/gcp/cdl/topics/google-cloud-databases for the storage decision framework.
• Messaging: Pub/Sub delivers events to Cloud Run services via push subscriptions, enabling event-driven container architectures.
• Observability: Cloud Logging, Cloud Monitoring, and Cloud Trace automatically ingest container logs and metrics with minimal configuration.

For the broader compute decision framework that places containers in context with App Engine and Cloud Functions, see /en/certs/gcp/cdl/topics/google-cloud-compute-options. For why this modernization saves money and accelerates teams, see /en/certs/gcp/cdl/topics/cloud-value-proposition.

Cost and Operational Comparison

A side-by-side cost lens often clarifies the choice between VMs and containers for CDL scenarios.

• Compute Engine (VMs): Pay per second for the whole VM (1-minute minimum), regardless of CPU utilization. Sustained Use Discounts apply automatically; Committed Use Discounts unlock 20 to 60 percent savings over 1- or 3-year terms. Spot VMs drop the price 60 to 91 percent for fault-tolerant workloads. The risk: idle VMs still cost money.
• GKE Standard: Pay for the node VMs (Compute Engine pricing) plus a small cluster fee. Workload density matters — pack more pods per node to amortize node cost.
• GKE Autopilot: Pay per pod-second of requested vCPU, memory, and ephemeral storage. No idle node cost — closer to a serverless billing model while keeping the Kubernetes API.
• Cloud Run: Pay per 100ms of CPU and memory while serving requests, plus a small per-request charge. Scale-to-zero is automatic and unavoidable on the default tier.

For a steady-state internal application running 24/7, Compute Engine with CUDs is often cheapest. For a bursty public API, Cloud Run wins on cost. For a microservices architecture with dozens of internal services, GKE Autopilot balances cost and orchestration capability.

Security Posture: Containers vs VMs

Container security is its own discipline, but the CDL-level summary is straightforward:

• VMs isolate at the hardware level via the hypervisor, which makes cross-VM compromise extremely difficult. Confidential VMs add hardware memory encryption on AMD SEV or Intel TDX silicon.
• Containers isolate at the kernel level via namespaces and cgroups. A kernel vulnerability could in theory let one container escape to attack another, so defense-in-depth matters: GKE Sandbox (gVisor) adds a user-space kernel between the container and the host kernel; Binary Authorization enforces that only signed, scanned images deploy; Workload Identity removes long-lived credentials from containers.

For most workloads, container security with Binary Authorization, vulnerability scanning, and Workload Identity provides excellent protection. For top-tier compliance requirements, Confidential VMs or Confidential GKE Nodes add a hardware encryption layer.

Frequently Asked Questions

Q: Are containers always faster than virtual machines?

A: For boot time and packaging size, yes — containers start in seconds because they reuse the host kernel and ship only the application layer, while VMs take 30 to 90 seconds to boot a full OS. For steady-state runtime CPU performance, the difference is negligible — both run on the same physical hardware. The container advantage is in density, startup, and deployment speed, not raw compute throughput.

Q: Can I run a Compute Engine VM inside a container, or vice versa?

A: A container always runs on top of an OS, which itself usually runs on a VM (or bare metal) — so containers run "inside" VMs in the literal sense. The reverse is not practical: you cannot run a full VM inside a standard container because containers share the host kernel. Nested virtualization on Compute Engine lets you run VMs inside VMs for niche use cases like running KVM in your own lab environment.

Q: Is Cloud Run a managed Kubernetes service?

A: No. Cloud Run is a serverless container platform built on the open-source Knative project, but it does not expose the Kubernetes API. You cannot use kubectl against Cloud Run. If you need Kubernetes-native features — operators, custom resources, multi-container Pods, StatefulSets, DaemonSets — use GKE Autopilot or GKE Standard. If you only need to run a stateless HTTPS container with scale-to-zero, Cloud Run is simpler.

Q: When should an enterprise pick GKE Standard over GKE Autopilot?

A: GKE Standard makes sense when you need fine-grained node control — custom machine types not yet supported by Autopilot, specific kernel parameters, DaemonSets that must run on every node, GPU or TPU workloads with niche driver requirements, or licensing models that demand specific instance shapes. For everything else, GKE Autopilot is the recommended default because it removes the operational burden of node management.

Q: Do containers replace the need for Compute Engine entirely?

A: No. Compute Engine remains the right answer for legacy workloads that cannot be containerized, GPU/TPU training jobs, license-locked software, specific kernel or driver needs, and strong-isolation compliance requirements. The modern pattern is to run new workloads on Cloud Run or GKE while keeping legacy workloads on Compute Engine, then migrate selectively using Migrate to Containers when the business case is strong.

Q: What is the difference between Container Registry and Artifact Registry?

A: Container Registry is the older Google Cloud product (deprecated in 2023). Artifact Registry is the modern replacement that stores not only container images but also Maven, npm, Python, Go, and OS package artifacts in a single managed service. New projects should use Artifact Registry exclusively; existing Container Registry users have a migration path.

Summary

The containers vs. virtual machines decision is fundamental to every modern Google Cloud architecture:

• Virtual machines (Compute Engine) deliver full OS control, hardware-level isolation, and broad compatibility — at the cost of slower boot times, lower density, and higher per-workload overhead.
• Containers (GKE, Cloud Run) deliver second-level startup, high density, and image portability — at the cost of sharing the host kernel and requiring an image-building discipline.
• Artifact Registry is the secure home for container images, paired with Container Analysis scanning and Binary Authorization policy enforcement.
• Kubernetes (delivered as GKE Autopilot or GKE Standard) orchestrates containers at scale with pods, deployments, and services.
• Cloud Run runs containers serverlessly — scale-to-zero, per-request billing, any language — but is not a Kubernetes API.
• VMs still win for legacy apps, GPU workloads, license-locked software, and strong-isolation compliance.
• The Google Cloud modernization journey is M2VM → M2C → serverless: lift-and-shift first, containerize second, refactor toward Cloud Run and Cloud Functions third.

As a Cloud Digital Leader, your job is to recognize each scenario's primary constraints — OS control, scaling speed, cost, compliance, team expertise — and map them to the right runtime: Compute Engine for VMs, GKE for orchestrated containers, Cloud Run for serverless containers. Master this mapping and you will confidently answer any containers-vs-VMs question on the CDL exam.