Card 02/ 05
Containers vs Virtual Machines
Both look like a separate machine from inside; only one has to boot a kernel first.
A container and a virtual machine both give a program something that looks like a computer of its own. A virtual machine does it by running a complete second operating system, kernel included, on simulated hardware. A container does it by giving an ordinary process a private view of the machine it is already on. The table puts the two side by side, and the last paragraph says when to use each.
| Compared on | Container | Virtual machine |
|---|---|---|
| What starts | A process | A kernel, then an init system, then your process |
| How long | Milliseconds | Tens of seconds |
| What separates it | Kernel features, on a shared kernel | A boundary drawn in hardware |
| Can run another OS | No, the kernel is the host's | Yes |
The first two rows follow from the third. A virtual machine has to start a kernel and an init system (the first program an operating system runs, which starts everything else) before your program can run, so it takes tens of seconds. A container starts only your program. The last row is the price of that speed: because a container uses the host's kernel, a Linux container cannot run a program built for Windows, and a flaw in the shared kernel affects every container on it.
Reach for a container when you want the Linux you already have, packaged so it runs the same on someone else's machine. Reach for a virtual machine when you need a different kernel, or a boundary strong enough to put someone you do not trust behind.
← → move through sections and cards