Why Docker? The Image API is Everywhere.

Noah Zoschke
Jun 30, 2016 · 6 min read

The most common question to my Docker For Mac Beta Review is: Why use Docker at all?

The reason to use Docker is for its modern packaging and runtime APIs. The Docker Image and Container APIs have become a de facto standard. Every major computing platform— from OS X to AWS — now has native support for working with Docker Images and Containers.

This happened because Docker presented a modern, API first approach to distributing and running software at the exact time when we all want cloud providers interoperate better.

This is an unprecedented feat of cooperation across the industry and makes these Docker APIs the obvious best system to target.

Docker Docker Docker!

Note: This post lives on the Convox Blog and is cross-posted here. I encourage you to read it there and subscribe to the @goconvox twitter for more cutting-edge research, development and products around all things AWS, Docker, containers, golang and more. — Noah Zoschke

Packaging Before and After Docker

Packaging is nothing new. For decades we have been packaging Operating Systems as images to run with Virtual Machine software:

We have been building application package archives to run on another computer:

There has been plenty of work and tooling for systems to interoperate with the different archive formats but we can’t deny that virtual machine images are proprietary and clunky and application packages have been hard to build, maintain and distribute.

Docker changed all this with Images and the Image API.

With Docker, an entire operating system and application is:

Packaging for a modern Rails application. Ubuntu, Ruby, Node, Postgres, Mysql, Sqlite, NGINX batteries included!

Compared to building vendor specific VM images and OS specific application package archives, Docker Images are clearly a better format to target:

Process Management Before and After Docker

Process management is also nothing new. We are all intimately familiar with various operating system calls and interactive shells to run, introspect and stop processes.

Docker improved on all this with Containers and the Container API.

With Docker, every process is:

We are familiar with tools like `docker run`, `docker ps`, `docker stats`, `docker logs`, and `docker kill`. These are utilities that come out of the box with Docker that wrap the APIs.

Docker Tools in Production. No custom AMI required.

But now that everything on an system can be accomplished via well documented APIs and language client libraries like the go-dockerclient, extremely sophisticated process management systems have emerged.

A simple example is that `docker ps` works exactly the same on my OS X computer and on AWS, where `ps` doesn’t due to differences between the BSD and GNU implementations.

An extreme example is that AWS ECS turns one or more instances running `dockerd` into a compute cluster. You can ask this cluster to run 5 web processes and an agent will tell the Docker daemons to start the 5 web processes on different hosts. It will then constantly introspect the Docker daemons and will start a new container if it observes that a container failed.

Before Docker cluster computing has been tied very closely to a specific operating systems like RedHat Cluster Suite or Solaris Cluster and lots of platform specific glue. The Docker Remote APIs make cluster computing approachable for far more users.

Compared to previous process management techniques Docker Containers are clearly a better format to target. The engine runs everywhere and the API first design makes it easier to program around that any other systems programming techniques before it.

De Facto Standard

Docker’s initial hype was because the new Image and Container concepts and APIs are modern, powerful and actually fun ways to interact with a computer. Demos where `docker-compose up` brings up an entire application — including microservices and databases — proved that there is something new and exciting to the Docker tools.

Providers saw the trend and listened, making it possible to push Docker Images into systems in addition to their old, proprietary formats.

The next iteration of this concept will come from the Open Container Initiative, but we can all be certain that any other standards in this space will be heavily influenced and very compatible with the existing Docker APIs.

Industry Cooperation

Why Not Docker?

When talking about just the Image APIs I don’t see any reason why you wouldn’t target Docker Images when building something new.

I ask this question to you… Is there a distribution format that’s simpler, easier or more supported than Docker Images now?

That said, I do understand and share concerns about other parts of Docker.

For starters, if you’re happy with your current packaging and runtime solutions, don’t throw them away. Conservatism will pay off as the container space rapidly evolves. The hype cycle is definitely in effect.

Next, I recommend caution in going deeper into the Docker universe than Images and Container APIs right now.

There is interesting work in the Docker container scheduling space (Swarm, Mesos, Kubernetes, Nomad) but these are extremely complex systems that can bring in massive headaches for you and your team. These dynamic systems make networking, load balancing, logging and debugging harder than ever before.

I recently wrote up a bunch of the biggest challenges I have building systems on top of AWS ECS and that’s with letting Amazon operate most of the system.

If you don’t know what you are doing, you can end up with a Docker system that is overly complex on the container, network, persistence and scheduling fronts.


Why Docker? We have always needed tools to package, distribute and run software. Docker took a fresh approach to all this and is now widely supported across the entire industry.

Building Docker Images and running software with the Docker Container APIs guarantees operability between every personal computer and CI and Cloud providers.

Building AMIs, making Homebrew scripts, managing APT repositories and and writing custom shell scripts and Makefiles didn’t come anywhere close.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade