01 — What Is Docker? Containers, VMs, and the End of 'Works on My Machine'

"A faster virtual machine" was my Docker model, and it leaked in every direction — resource claims, startup, isolation. The idea that finally separated the threads: a container is just a process on your machine, walled off by Linux kernel primitives, with its filesystem and dependencies frozen into a portable image. [1][3]

The framing that landed for me is the contrast, not the tool in isolation. Before containers, shipping an app meant shipping it with an operating system, or praying the destination machine had the right OS, library versions, and config. Docker collapses both problems by packaging the app and everything it needs into one unit that runs the same everywhere, while reusing the host's kernel instead of booting a fresh one [1][5]. Once I could see how that differs from a VM, most of Docker's design stopped feeling arbitrary.

The problem: "works on my machine"

The thing I had to see clearly is why anyone built this. The "need for containers" is a story about environment drift — the set of versions and config my app needs on my laptop slowly diverging from what a teammate has, and from what production runs [4]. The classic symptom is the phrase every team learns to dread: "it works on my machine."

Containers solve that by standardizing the runtime environment. The app, its language runtime, its libraries, its system tools, and its config all go into one image. That image is a fixed, immutable artifact. Run it on my laptop, on a teammate's laptop, or on a production server, and it boots the same way, because the only thing it borrows from the host is the kernel [1][5]. The drift simply has nowhere to hide.

Bare metal, VM, container

The cleanest way I found to pin down a container is to put it next to the two things it's not. Three deployment models, one trade-off axis — isolation versus overhead:

• Bare metal runs the app directly on the host operating system and hardware. Nothing is duplicated, so performance is maximal — but there's no isolation, and the app is welded to that one machine's config [6].
• Virtual machines sit on a hypervisor — a layer that fakes a complete computer — and each VM runs its own full guest operating system. Isolation is excellent, because each app genuinely believes it owns a separate machine. The cost is overhead: booting and running a whole OS per app burns RAM, disk, and CPU [7].
• Containers skip the guest OS. Each container holds the app plus its own bins and libraries, but they all share the host kernel. That makes them tiny — megabytes, not gigabytes — and near-instant to start, because no OS boots [1][3].

The part that clicked: a VM virtualizes hardware; a container virtualizes the environment around one process. Same isolation goal, very different cost.

What a container actually is

With the contrast in place, the definition gets precise. A container is a lightweight, standalone, executable package — application code plus its runtime, libraries, and system tools, all wrapped so the whole thing runs in an isolated environment [3]. When you start it, the host kernel runs the app as an ordinary process, but kernel features (namespaces, cgroups — covered in the next post) make that process believe it has its own filesystem, network, process list, and user tree [1]. From the inside, it looks like a private machine. From the outside, it's one PID in ps.

Two artifacts make this work, and I conflated them for too long:

• An image is the frozen, read-only blueprint — the layered filesystem plus metadata. It's a file you can push and pull like any other.
• A container is a running instance of an image — the image plus a writable scratch layer on top, plus a live process. One image, many containers; stop the container and the writable layer goes away unless you persist it [10].

OCI: the reason it's not just "Docker"

The last idea worth holding onto is that Docker is one implementation of an open standard. The Open Container Initiative (OCI) is a Linux Foundation project that defines the format for container images and the runtime that executes them [2][8]. Practically, that means an image built with Docker can be run by other runtimes (containerd, runc, Podman), and the ecosystem can't be locked into one vendor. When the roadmap talks about "Docker and OCI," this is the whole point — interoperability through agreed specifications [2].

This is why I no longer think of "Docker" and "container" as synonyms. Docker made containers famous and still has the smoothest tooling; the format and the concept belong to OCI now [8].

How I use this

The practical payoff is a decision check before I reach for any virtualization. When I need strong security isolation between mutually distrustful tenants, I lean toward a VM — a full kernel boundary is harder to escape than a process boundary. When I need to ship an app that runs the same way across dev, CI, and prod, with fast starts and low overhead, I reach for a container. Most of my work is the second case, which is why Docker is the default in my stack. And when I describe a container to someone now, I lead with "a walled-off process sharing the host kernel," not "a lightweight VM" — because the process framing is what actually predicts how containers behave.

References

[1] Docker, Inc., "What is a Container?," docker.com, 2024. [Online]. Available: https://www.docker.com/resources/what-container/

[2] Open Container Initiative, "Open Container Initiative," opencontainers.org, 2024. [Online]. Available: https://opencontainers.org/

[3] Amazon Web Services, "Introduction to Containers," AWS Skill Builder, 2024. [Online]. Available: https://explore.skillbuilder.aws/learn/course/106/introduction-to-containers

[4] Red Hat, "What are containers?," redhat.com, 2024. [Online]. Available: https://www.redhat.com/en/topics/containers

[5] Docker, Inc., "Docker Overview," Docker Docs, 2024. [Online]. Available: https://docs.docker.com/

[6] Cloud Native Computing Foundation, "Bare Metal Machine," CNCF Glossary, 2024. [Online]. Available: https://glossary.cncf.io/bare-metal-machine/

[7] Microsoft Azure, "What is a Virtual Machine?," Azure Cloud Computing Dictionary, 2024. [Online]. Available: https://azure.microsoft.com/en-au/resources/cloud-computing-dictionary/what-is-a-virtual-machine

[8] Wikipedia, "Open Container Initiative," 2024. [Online]. Available: https://en.wikipedia.org/wiki/Open_Container_Initiative