Topic 0.2
Virtual Machines vs Containers
In one line
Both give you isolation, but at completely different layers of the stack — understanding exactly WHERE each one draws its line is the single most-asked Docker fundamentals question.
Think of it like this
A VM is like building a separate house for every tenant (own foundation, own plumbing, own everything) — safe and fully isolated, but expensive and slow to build. A container is like giving each tenant their own locked apartment in ONE shared building (shared foundation/plumbing/electricity, but private rooms) — much cheaper and faster to set up, while still keeping tenants from interfering with each other.
Key ideas
- 01
Stack view, bottom to top: Hardware → Host OS → [VM: Hypervisor → Guest OS → App] vs [Container: Docker Engine → App]. The container skips an ENTIRE operating system layer (the Guest OS) by reusing the host's kernel.
- 02
Because a container has no separate kernel, it CANNOT run a different kernel than the host — you can't run a Windows container on a Linux host's kernel directly (Docker Desktop on Windows/Mac actually runs a lightweight Linux VM under the hood to provide that Linux kernel to containers).
- 03
Resource footprint: a VM typically needs gigabytes of disk and dedicated RAM/CPU allocation even when idle. A container image can be tens of megabytes, and an idle container uses close to zero extra resources beyond the process itself.
- 04
Isolation strength: a VM's isolation is enforced by the hypervisor at the hardware-virtualization level — very strong, harder to escape. A container's isolation is enforced by OS-level features (namespaces, cgroups — Phase 1 covers these) — strong for most purposes, but a kernel-level container escape is a more realistic threat model than a hypervisor escape, which matters for Phase 7's security topic.
- 05
When to still reach for a VM: running a genuinely different OS/kernel, needing hypervisor-grade security isolation for untrusted multi-tenant code, or legacy apps that assume a full dedicated OS.
In your stack
- →
A common real setup: a single physical/cloud server running a hypervisor with 2-3 VMs (say, separating 'prod' and 'staging' network zones), and INSIDE each VM, Docker runs dozens of lightweight containers — one per Spring Boot microservice. VMs give the heavy security/network boundary; containers give the fast, dense app packaging within it.
Code & diagrams
The exact layer each approach skips is the whole story.
Explain it without notes
Why can't you run a container built for a Linux kernel feature directly on a bare Windows kernel, and how does Docker Desktop work around this?
A colleague says 'containers are just lightweight VMs.' Correct this statement precisely.
Practice
Draw (on paper) the two stacks from this topic's diagram from memory, labeling every layer.
Find one real scenario at a company you know (or imagine one) where a VM would still be the right choice even though Docker is available.
Trade-offs
- ↔
Containers win on speed, density, and simplicity for the vast majority of app-deployment cases. VMs win when you need a genuinely different kernel, or when the isolation boundary must be as strong as physically separate hardware.
Done when you can
I can draw both stacks from memory and point at exactly which layer containers skip.
I can name at least one legitimate reason to still use a VM over a container.