Why Docker’s Patchwork of Legacy Tech Still Dominates Cloud Computing

In 2013 Docker was released; twelve years later Docker Hub hosts over 14 million images, sees more than 11 billion pulls per month, and Dockerfiles appear in over 3.4 million public GitHub repositories, while Stack Overflow repeatedly names Docker the most wanted and used tool.

Docker, however, did not invent new technology. Its core features are assembled from older mechanisms:

chroot (Unix V7, 1978)

Filesystem namespaces (Linux 2.5.2, 2001)

Network namespaces (Linux 2.6.24, 2007)

Layered image format – essentially tar‑on‑tar

Running Linux containers on macOS/Windows via the ancient SLIRP tool (mid‑1990s dial‑up networking utility)

Cross‑CPU execution using QEMU and the binfmt_misc kernel feature

Even though these pieces are dated, Docker won the cloud‑infrastructure war. The article asks why a tool that “doesn’t require any original invention” became the cloud’s operating system.

Perfect‑Solution Graveyard

The “graveyard” contains technically superior alternatives that Docker displaced:

Plan 9 : Designed a unified namespace from the ground up, unlike Linux’s piecemeal, six‑year‑long namespace patches.

Full virtualization : Provides true isolation with separate kernels, but incurs tens of seconds startup time, making it unattractive for everyday developer workflows.

Nix/Guix : Offer reproducible, conflict‑free package management via hash‑based store paths, yet require the entire software ecosystem to be rebuilt in Nix format.

In each case Docker wins because it imposes virtually no changes on developers: write normal code, use existing package managers, and let Dockerfile (a thin shell‑script wrapper) handle packaging.

SLIRP Legend

When Docker for Mac needed to run Linux containers on macOS, the straightforward solution was to ship a full VM (e.g., VMware Fusion). Docker rejected this as a poor user experience. Instead, they embedded a complete Linux kernel inside the desktop app using HyperKit and routed container network traffic through SLIRP, a user‑space TCP/IP stack originally built for 1990s PalmPilot dial‑up connections. This avoided bridge networking that firewalls would block, reducing bug reports from enterprise users by over 99 %.

FROM python:3
COPY requirements.txt /app/requirements.txt
WORKDIR /app
RUN pip install -r requirements.txt
COPY . /app
EXPOSE 80
CMD ["python", "app.py"]

The Dockerfile simply expresses the developer’s existing steps; Docker adds no new language or concepts.

Pragmatic Engineering Law

The article proposes a law: “In the real world, a technology’s victory depends not on how correct it is, but on how little it forces the existing world to change.” Plan 9 required a global OS rewrite, Nix demanded a new package manager, and VMs added seconds of latency. Docker asks for nothing—just package what you already have.

Docker’s stack is a “code‑city built from old bricks”: a 1978 chroot foundation, namespace patches from 2001‑2007, a 1990s SLIRP networking layer, QEMU for CPU translation, and overlayfs copy‑on‑write from embedded‑device flash‑wear research.

Component Decomposition

Since 2016 Docker split its monolith into independent components: containerd runs containers, BuildKit builds images, and dockerd schedules them. The team claims this modularity lets the community replace any piece, yet no alternative (Podman, Kaniko, nerdctl) has displaced Docker because the OCI image format still bundles all the legacy pieces Docker painstakingly integrated.

GPU Support – Another Patch

With heterogeneous AI workloads, Docker introduced the Container Device Interface (CDI) to inject GPU device files and libraries at container start‑up, a simple “another patch” rather than a universal GPU abstraction layer.

Conclusion

Docker’s success illustrates that “good enough” engineering—leveraging existing, imperfect components without demanding ecosystem overhaul—can outcompete technically superior designs. The world is built from decades‑old artifacts; Docker merely acknowledged and repurposed them, becoming the first widely adopted “legacy‑tech‑first” platform.