Docker: why a container isn't a tiny virtual machine

The classic pain of shipping software is "it works on my machine." Your app needs a specific Python version, three system libraries, and an environment variable — and the server has none of them. Docker solves this by packaging your app together with everything it needs to run into a single portable unit called a container, built from a recipe file (the Dockerfile) and a reusable snapshot (the image). The same image runs identically on your laptop, a teammate's machine, and production.

The non-obvious part is what a container actually is. People assume it's a lightweight virtual machine, but it isn't. A virtual machine boots a whole guest operating system with its own kernel on top of emulated hardware. A container has no kernel of its own — it shares the host's Linux kernel and is really just a normal process that the kernel has fenced off. Two kernel features do the fencing: namespaces give the process its own private view of things like the filesystem, process list, and network, while cgroups cap how much CPU and memory it can use.

Because there's no guest OS to boot, containers start in milliseconds and are small enough to run dozens on one machine — the key reason Docker took over deployment and made tools like Kubernetes possible. The tradeoff: since containers share the host kernel, they're more isolated processes than sealed machines, so a Linux container needs a Linux kernel (on Macs and Windows, Docker quietly runs one inside a small VM).