Docker Isn't a VM. Here's What It Actually Is.

Installing mental model for docker.

Everyone says Docker is a lightweight virtual machine. Every tutorial shows the same diagram. Hardware, hypervisor, guest OS on one side. Hardware, kernel, containers on the other.

And that diagram is fine. But it's hiding something. Something that changes how you think about containers entirely.

A container doesn't create a fake computer. It doesn't boot an operating system. There is no guest kernel.

Watch what actually happens.

To understand why this matters, let's look at what a VM actually does.

A virtual machine creates a fake computer. Virtual CPU. Virtual RAM. Virtual disk. Virtual network card. The hypervisor manages this illusion, giving each VM its own isolated hardware.

The guest OS has no idea. It boots up. Loads drivers. Runs its init system. A complete operating system, running inside another operating system.

And here's the cost. A typical Linux VM image is hundreds of megabytes. The app running inside it might be fifteen. You're shipping an entire house just to run one appliance.

A container is just a process. A regular Linux process. Running on the same kernel as everything else. No virtual hardware. No guest OS.

But the kernel plays a trick. It gives this process a restricted view of the world. And it does this with two features.

First, namespaces. Namespaces control what the process can see.

There are several kinds, but the most dramatic one is the PID namespace. Right now, this Linux system has hundreds of running processes. Watch what happens when we put this process in its own PID namespace.

The entire process tree disappears. This process thinks it's PID one. It thinks it's the only thing running. But the host still sees it. Same process, two completely different views.

Network namespaces do the same trick with networking. The process gets its own IP address, its own ports. Two containers can both listen on port eighty because they each have their own network namespace.

Mount namespaces give it a different filesystem. The container sees a completely different set of files and directories than the host. Same kernel. Different view.

Second, cgroups. Cgroups control what the process can use. The kernel sets hard limits. This container gets two gigs of memory. This one gets half a CPU core. Exceed your memory limit, and the kernel kills your process. Exceed your CPU limit, and you get throttled.

That's it. A container is a process with blinders on. Namespaces restrict what it sees. Cgroups restrict what it uses. No virtual hardware. No second kernel. Just isolation applied to a normal process.

But there's one more trick that makes containers practical. The filesystem.

When you write a Dockerfile, each instruction creates a layer. Install Python, that's a layer. Copy your app code, another layer. These layers are read-only and stackable.

Here's why that matters. Say you have a base image that's two hundred megabytes. You spin up fifty containers from it. A VM approach would cost ten gigabytes. But with containers, all fifty share the same read-only layers. Each container just gets its own thin writable layer on top.

Fifty containers, all sharing those same base layers. Instead of fifty copies, you store it once.

When a container needs to change a file, it copies just that file to its own writable layer. Everything else stays shared. This is called copy on write, and it's why containers are so efficient with storage.

So what does all this mean in practice?

Speed. A virtual machine boots an entire operating system. That takes tens of seconds. A container just starts a process. Often under a second.

Density. Where you could run maybe ten or twenty VMs on a server, you can run hundreds of containers. Because each container is just a process. There's no second operating system eating your resources.

But here's the tradeoff. Every container shares the same kernel. If the kernel has a vulnerability, every container on that host is exposed. VMs provide stronger isolation because each one runs its own kernel. Containers can be hardened with additional security layers, but the shared kernel is a fundamentally different trust model.

That's why in production, it's common to run containers inside virtual machines. You get the isolation of a VM and the density of containers.

So the next time someone says Docker is a lightweight VM, you'll know the truth. It's not a VM at all. It's something simpler. A process, with the kernel playing tricks on what it can see and what it can use.

Cognitive architecture... updated.