1.3.1 Virtual Machine Contrast

The virtual machine contrast is the comparison between how Docker containers and virtual machines achieve isolation and packaging, highlighting that the two technologies solve a similar problem — running an application in its own controlled environment — through fundamentally different mechanisms.

Different Layers of Virtualization

A virtual machine virtualizes hardware: a hypervisor presents each VM with what appears to be its own CPU, memory, disk, and network interface, and a full guest operating system, including its own kernel, runs on top of that virtual hardware. A Docker container virtualizes at the operating system level instead: it shares the host's kernel and uses kernel features such as namespaces and cgroups to isolate processes, filesystems, and resource usage.

VM:        Hardware -> Hypervisor -> Guest OS (own kernel) -> Application
Container: Hardware -> Host OS (shared kernel) -> Container -> Application

Startup Time and Resource Overhead

Because a VM must boot an entire guest operating system, starting one typically takes tens of seconds and consumes a fixed allocation of memory and CPU regardless of what the application inside it is doing. A container starts as quickly as its main process starts, since there is no separate kernel to boot.

time docker run --rm alpine echo hello

This command typically completes in well under a second, a stark contrast to virtual machine boot times.

Isolation Strength

A VM provides strong isolation because each guest has its own kernel; a vulnerability in one VM's kernel does not directly expose other VMs on the same hypervisor. A container's isolation is weaker in this specific respect, since a kernel-level vulnerability can, in principle, be exploited to affect other containers sharing that same kernel — a tradeoff made in exchange for the lighter weight and faster startup containers provide.

Density Differences

Because each VM carries the overhead of a full guest OS, a host can typically run far fewer VMs than containers, since containers share the host kernel and avoid duplicating that overhead per instance.

docker run -d --memory=128m myapp:lightweight

A container can be constrained to a small memory footprint in a way that would be impractical for a full VM, which always needs enough memory to run its entire guest operating system.

When Each Is the Better Fit

The virtual machine contrast is not a simple "containers are always better" conclusion: workloads needing strong isolation between untrusted tenants, or requiring a different kernel or operating system than the host provides, are better served by virtual machines, while workloads optimizing for density, startup speed, and consistent packaging across many instances are typically better served by containers.