This last week I read a book that I would recommend to just about anyone: The Box by economic historian Marc Levinson. I picked up the book because I wanted to explore the analogy between the containerization movement in Cloud Computing led by Docker and shipping containers —- you know, those enormous, colorful boxes you see piled up at every shipyard on the planet nowadays.


The analogy is not a new one —- after all, you even see it in Docker’s logo —- but I wanted to explore two things: (1) just how much the analogy can tell us about the nature and promise of LXC-type containers; and (2) where does the analogy break down and why we should have a look into the world of gardening, of all places, to complete our understanding of this nascent software packaging and deployment technology.

In the Beginning, There Was a Mess

The Box is a wonderful book because it vividly explains how something that seems so simple and, in retrospect, just plain obvious, came to act as a pillar of international trade and the global economy as we know it. To me, the most compelling part of Levinson's history comes in the second chapter, "Gridlock on the Docks," where he describes just how frighteningly inefficient and haphazard the shipping industry was before the advent of shipping containers.

He describes docks on which "swarms of workers clambered up gangplanks with loads on their backs" (p. 16), ship holds full of items of all kinds sorted and stacked based on the whims of the people sorting and stacking, ships spending days if not weeks in port while longshoremen—often disgruntled and prone to labor unrest—moved items by hand. Perishable goods often perished; fragile goods often broke.

The end result: shipping goods was a haphazard, wasteful process, with costs high enough to deter many industries from even attempting to engage in global trade.

And Then Blessed Relief: The Container

While Levinson spends chapters 3 through 12 telling the story of Sea-Land, the company most responsible for making containers the norm in the industry, it's in chapter 13, "The Shippers' Revenge," that he paints the picture of the new, containerized world most clearly: shipping costs dramatically reduced; ships spending hours or less at dock instead of days or weeks; massive cranes loading and unloading ships with dexterity and grace; and fragile goods safe inside sturdy walls.

The end result: shipping costs are transformed into a rounding error on the total costs of goods, decaying industries are revitalized, and new industries are born that were previously impossible. As Levinson notes: "Low transport costs helped make it economically sensible for a factory in China to produce Barbie dolls with Japanese hair, Taiwanese plastics, and American colorants, and ship them off to eager girls all over the world” (p. 265). To put it a different way, try to imagine the tech industry as we know it today without cheap shipping. Spoiler alert: say goodbye to your iPhones and your commodity servers.

Docker Containers: Light, Modular, Sane

It should be pretty clear already why I like the shipping container analogy for Docker so much. Docker containers are like shipping containers because they are so self-sufficient. All that they ask is that they are run by a sufficiently powerful operating system. That's the extent of their "contract" with their environment. Similarly, shipping containers don't care which ship they're on, as long as the ship is sturdy enough to carry them. No need to stack goods by hand below deck and worry about temperature, moisture, etc. The container takes care of that, not the ship.

I also like the analogy because of the depth of the changes wrought by shipping containers. As Levinson says, "the cost of transporting goods was decisive in determining what products they would make, where they would manufacture and sell them, and whether importing or exporting was worthwhile" (p. 246). Shipping containers didn't just cut costs and change decision making. They changed the whole economic landscape, altering global consumption patterns, revitalizing industries in decay, and even allowing new industries to take shape.

In short, shipping containers remade global trade in their own image. I truly think that the same can be said for Docker containers in IT. Why? Because they don't just trim the fat in operating costs or streamline this or that process. They are a potential game-changer just like shipping containers were for global trade.

The Limit of the Analogy: It Matters when Shipping Containers Break

The shipping container analogy is apt, but for me it completely breaks down on one crucial point: when shipping containers go down, their cargo is lost. If a ship sinks or if the basic integrity of a shipping container is compromised, everything in it is (or can be) lost forever. Docker containers don't work this way. When they go down, you simply rebuild the container.

In this sense, Docker containers are more like plants than shipping containers. If a plant dies, you simply plant a seed and replace it. If the environment surrounding the plant is the same, you'll end up with an essentially identical plant. If a Docker container goes down—the machine it's running on goes haywire, the OS runs out of memory, etc.—the consequences are far from dire. You can simply use the old container's Dockerfile (think of it as a container seed) to sprout a new container identical to the old one. Even better, Dockerfiles, like seeds, tend to be quite small (usually less than a kilobyte), but they can grow into mighty oaks.

The beauty of Linux containers is that they are ephemeral in a way that shipping containers could never even hope to be. Let's say that you "lose" a container because someone pours coffee on the server it's running on. The consequences? Minimal. In the right orchestration environment, a few keystrokes will tell another, functioning server what to do: look at the Dockerfile, see what needs to be built and what commands need to be run, and go. In an even better scenario, your orchestration environment would know that the container had gone down and would automatically create a new one. Or perhaps a fallback container exists that can be switched to immediately. The possibilities are vast.

The Challenge Going Forward

Docker containers are a beautiful thing because they combine the modularity of shipping containers with the ephemerality of plants. The promise of Docker for transforming IT from the ground up are clear—and if they're not clear yet, then stay tuned here, because there's lots more on the way. But the problem is that the promise of Docker remains just that: a promise.

To see why, we need to look to shipping containers and gardening once again. Shipping containers are immensely useful, but they don't ship, stack, or unload themselves. They require the infrastructure surrounding them to realize their potential. Similarly, just because seeds can turn into plants doesn't mean that cultivation is always easy. A skilled gardener has to have a strong organizational acumen to orchestrate a proper garden.

As it stands, the infrastructure necessary to realize the promise of Docker containers is on the way, but it hasn't arrived yet. Container orchestration at scale remains a challenge, but tens thousands of really smart developers are working to resolve turn this promise into a reality, and we hope that this analogy helps illustrate how just how important this work is.