Chapter 45 — Containers vs. virtual machines, honestly compared

In one sentence

A virtual machine virtualises the HARDWARE (each VM runs its own full kernel, on emulated or hypervisor-managed hardware), while a container virtualises the OPERATING SYSTEM (many containers share one real kernel) — a genuinely different point in the isolation-vs-overhead trade-off, not simply "containers are the new, better VMs."

Why this matters

"Should this run in a container or a VM" is a real, recurring architecture decision, and answering it well requires understanding the actual trade-off, not a marketing simplification.

How it actually works

   A VIRTUAL MACHINE, via a HYPERVISOR (software like KVM, Xen, or
   VMware that can run directly on hardware, or on top of a host OS):
     - virtualises actual HARDWARE -- CPU, memory, disk, network devices
       are all presented to the guest as if they were real.
     - each VM runs its OWN, COMPLETE, INDEPENDENT KERNEL -- genuinely
       a separate operating system instance, which can even be a
       DIFFERENT OS entirely from the host (a Linux host running a
       Windows VM, for example).
     - ISOLATION is very strong: a kernel bug or crash inside one VM
       cannot directly affect another VM or the host's own kernel,
       because they're not sharing one.
     - COST: a full kernel boot, a larger memory footprint per instance,
       and generally SLOWER startup (often tens of seconds or more) and
       lower density (fewer instances per physical machine, for the same
       hardware).

   A CONTAINER, as Chapter 44 established:
     - shares the HOST's SINGLE kernel -- every container on a machine
       is running on the SAME kernel, at the SAME time.
     - isolation comes from namespaces + cgroups, at the OS level, not
       hardware virtualization.
     - STARTUP is typically near-instant (milliseconds, Chapter 46
       explains why) since there's no kernel to boot -- you're just
       starting a process.
     - DENSITY is far higher for the same hardware -- no per-instance
       kernel memory overhead, much smaller per-instance footprint.
     - the TRADE-OFF: isolation is WEAKER than a VM's -- a sufficiently
       severe kernel vulnerability, or a container-escape technique
       (a real, actively-studied security category, covered in this
       wiki's security guides), can potentially cross between
       containers, or from a container to the host, in a way a
       properly-configured VM's hardware-level boundary generally
       resists more strongly.

   THIS IS WHY "SANDBOXED" CONTAINER RUNTIMES EXIST (gVisor, Kata
   Containers, covered in this wiki's advanced security guide) -- they
   sit deliberately IN BETWEEN: Kata runs each container in its own
   lightweight VM (closer to VM-level isolation, container-like
   ergonomics); gVisor intercepts and re-implements syscalls in
   userspace rather than passing them straight to the host kernel. Real
   engineering teams choose points along this spectrum based on how much
   they trust the WORKLOAD running inside.

Real-world example

   The industry-wide shift toward running MORE workloads in containers
   rather than one-VM-per-application, over roughly the 2014-2020
   period, is a well-documented, real architectural trend, driven
   directly by this chapter's density and startup-time trade-offs:
   companies operating at real scale (running thousands of application
   instances) found that packing many containers onto shared hosts --
   instead of many separate, per-application VMs, each paying its own
   full-kernel memory and boot-time overhead -- meaningfully reduced
   infrastructure cost and dramatically improved how quickly new
   instances could be started (critical for AUTOSCALING responsively to
   real traffic spikes, since a VM that takes 30-60 seconds to boot
   responds to a traffic spike far more sluggishly than a container that
   starts in under a second). This is precisely why Kubernetes (Part 16)
   -- designed around exactly this rapid-start, high-density model --
   became the dominant orchestration layer for this style of workload,
   while VMs REMAIN the right, still-widely-used choice for workloads
   needing stronger isolation guarantees (genuinely multi-tenant,
   security-sensitive workloads; running a different OS entirely; very
   large, long-lived, stateful single instances) -- this is a real,
   ongoing trade-off decision, not a settled "containers won" story.

Try it yourself

# Feel the startup-time difference directly (VM comparison is
# illustrative -- most readers won't have a VM handy to time, but the
# container side is immediate and real)
time docker run --rm alpine echo "started"    # note how fast this is
                                              # -- typically well under
                                              # a second once the image
                                              # is already pulled

# See how many containers you could plausibly run vs. how many full VMs
free -h                          # your available memory
docker run --rm alpine cat /proc/meminfo | head -1   # a minimal
                                                      # container's
                                                      # footprint is
                                                      # tiny -- no
                                                      # separate kernel
                                                      # to account for

Common mistakes

"Containers are just lightweight VMs." They're a fundamentally different isolation model (shared kernel vs. separate kernel) — the practical CONSEQUENCES (startup time, density) are similar in spirit, but the mechanism and the security trade-off are genuinely different.
Assuming containers are always the "better" choice. For genuinely untrusted, multi-tenant, or security-critical isolation needs, a VM's stronger boundary is often still the right, deliberate choice — this wiki's advanced security guide covers exactly this trade-off in production contexts.
Not knowing sandboxed runtimes (gVisor, Kata) exist. They're the real, practical middle ground when you want container-like ergonomics with closer-to-VM isolation strength.

Check yourself

What does a VM virtualise, and what does a container virtualise — state the difference precisely.
Why do containers typically start dramatically faster than VMs?
What trade-off do sandboxed runtimes like gVisor/Kata occupy, and why would a team choose one?