Containers vs virtual machines
Containers were not the first fix for the environment problem. Virtual machines (VMs) came first.
A VM is a complete simulated computer. A piece of software called a hypervisor carves your physical machine into fake machines, and each VM boots its own full guest operating system: its own kernel, its own system services, everything. Great isolation, but heavy. A VM image is often gigabytes and takes minutes to boot.
A container skips the guest OS. All containers on a machine share the host's kernel (the OS core that talks to hardware). Docker uses Linux kernel features called namespaces to isolate only what each container can see: its own filesystem, its own processes, its own network. So a container is just a normal process wearing a blindfold, which is why it starts in milliseconds.
Honest comparison
| VM | Container | |
|---|---|---|
| Starts in | minutes | milliseconds |
| Typical size | gigabytes | megabytes |
| Runs its own kernel | yes | no, shares host |
| Isolation strength | stronger (hardware-level) | good, but weaker |
| Per-machine density | a handful | hundreds |
Note the isolation row. VMs still win when you must run untrusted code or a different OS entirely, which is why cloud providers run your containers inside their VMs. For packaging and shipping your own apps, containers are the right default.
You will see this hybrid again in lesson 9-1 when we compare deployment options.
Quiz
Why does a container start in milliseconds while a VM takes minutes?
Quiz
You must run completely untrusted code submitted by strangers on the internet. Container or VM, and why?
Problem
Which technology shares the host machine's kernel instead of booting its own: containers or virtual machines?