How much do you know about containers?

Once upon a time, I worked at a startup that was looking to “Dockerize” its backend infrastructure. This developed into a running joke where the programmers on the team would ask me if I knew what Docker was, and I would say:

“Yes, it’s like a boat.”

This would frustrate the programmers, which was my intention. They would howl about how wrong I was, and they could never quite calm down enough to clarify how Docker wasn’t like a boat.

I was, of course, basing my concept of Docker entirely on the Docker logo, which is sort of a whale / boat hybrid, filled to the brim with shipping containers.

So, as a much-belated apology to those programmers I harassed, I’d like to try and explain Docker now.

Docker is like a boat. A Linux server is the ocean. Inside Docker are “containers” that carry applications or sets of applications.

Have you ever tried to install Minecraft and seen an error message like, “This application requires a Java Runtime Environment 1.6.0”? Or you try to install something on Windows, and you get an error that says some .NET framework is missing? Or, as a more basic example, have you ever spent a couple hours setting up a new computer with all your applications and preferences?

Those are the kinds of problems Docker, and “containers” more broadly (Docker is kind of the Kleenex of containers), are meant to solve. Docker makes it easy to install Linux applications on servers, along with their required dependencies and whatever preferences you might have for those applications. And, as an added bonus, conflicting dependencies between applications (maybe one app relies on Python 2, and another app relies on Python 3) aren’t an issue, because everything is isolated in different containers.

If this sounds like it would be convenient for desktop computing, you’re right. But it emerged in the developer world first because:

1. Developers like to scratch their own itch.

2. Developers spend a ton of time spinning up new servers to run the same sets of applications, and they got tired of doing all these fiddly installs over and over.

These days, backend developers have moved on to solving more elaborate problems, while typically using Docker or other container technologies as the unit of abstraction. For instance, Kubernetes is software that Google built to help with “container orchestration.” The Kubernetes logo is literally a boat’s steering wheel, but I think it should be an admiral’s hat because Kubernetes helps you organize a fleet of Docker boats, not just one.

So, why are you telling me this?

The same reason I got interested in this boat-like technology in the first place: spite.

In this case, I’m just trolling Nilay, who shooed me away from the topic of Docker on The Vergecast the other day. Nilay loves boats, so he really had no idea what he was missing.

But if we’re going to pretend to learn a valuable lesson from all of this, I think Docker, and containers generally, are an important element in the ongoing war against technological complexity that we all must face. We make systems, those systems become complex and fragile, so we build new abstractions to manage that complexity. The abstractions aren’t always correct, and so we figure that out on a case-by-case basis. Sometimes we can’t safely hide complexity, so we have to throw things out and write whole new systems. Either way, it’s hard to move forward and solve new problems until we pay our complexity debt.

And it never ends.

I believe it took roughly five seconds after Docker emerged on the scene for a developer to say, “If only I had a system to manage all my Docker containers!” And thus, Kubernetes was born. In my dreams, someone will soon discover a meta-Kubernetes that will orchestrate multiple Kuberneti.

Maybe they already have. They should call it “the king of the boat people,” but they’ll probably call it something simple and Unix-ey like “kops.”