Things Have History
Docker: the container that shipped the machine

software-architecture

Docker: the container that shipped the machine

Listen · 4:02

In March 2013, Solomon Hykes took the stage at the Santa Clara Convention Center during PyCon and gave a five-minute lightning talk to a room of Python developers. Behind him on the slide, slightly embarrassingly, the demo text read “Hello wowrld.” He spun up five, ten, fifteen, twenty Apache containers in seconds and sat back down. Within months, most of what he had shown would reshape how software got shipped.

Hykes had come to Santa Clara not to launch a product but to show off something his team at dotCloud had been building for themselves. dotCloud was a platform-as-a-service company he had co-founded in 2010 with Kamel Founadi and Sebastien Pahl, part of Y Combinator’s summer cohort that year. The business model — host web apps in any language — was struggling. The underlying machinery, the piece that spun up isolated environments fast and cleanly, was working extremely well. Hykes called it Docker, open-sourced it under the Apache 2.0 license, and drove back to San Francisco.

What Docker actually was, under the hood, was a packaging system built on top of existing Linux kernel features. Cgroups — control groups — were patches contributed by Google engineers Rohit Seth and Paul Menage in 2007; they imposed resource limits on processes, capping how much CPU or memory a given process could consume. Namespaces, developed across the early 2000s, gave each process its own isolated view of the system: a separate process tree, a separate network stack, a separate filesystem mount. Neither was new. Docker’s contribution was to bundle these mechanisms with three additions: layered filesystem images that could be cached and shared, a Dockerfile that expressed an environment as repeatable instructions, and Docker Hub — a public registry where you could push an image from your laptop and pull it to a server anywhere in the world.

The problem Docker solved had a name so well-known it qualified as gallows humor: “it works on my machine.” A developer would build an application against one version of a library on macOS; the production server would have a different version; something would break quietly in the night. Docker made the machine part of the artifact. You shipped the environment with the code. Whatever ran locally ran in staging, ran in production, ran anywhere.

Here is the detail that reframes the whole story. While Hykes was giving his five-minute talk to a roomful of Python developers, Google had been running containers at global scale for nearly a decade. The system was called Borg. It ran Search, Gmail, YouTube, and Maps as packed containers on shared hardware, treating the entire data center as a single pool of compute. Google had solved container orchestration years before the word became fashionable. It just hadn’t told anyone. The engineers who built Borg eventually left Google, watched Docker land, and built Kubernetes as its open-source successor.

By October 2013, dotCloud had renamed itself Docker Inc. By 2014, Red Hat had partnered with the project. That same year, Google open-sourced Kubernetes and handed it to the newly formed Cloud Native Computing Foundation. The combination — Docker for packaging, Kubernetes for orchestration — became the standard substrate on which a generation of microservice architectures would be built and run.

The five minutes in Santa Clara did not invent the container. They made it the default.

Sources

Spot a mistake?

Wrong date, broken citation, a fact that doesn't hold? Tell us. It lands in an inbox a human reads and the post can be pulled or corrected.