CoreOS Paves a New Containerized Path

The CoreOS team today announced the first release of Rocket. As I’ve clearly gone swimming in the Docker Kool-aid, I’ve also knocked back a goodly amount of CoreOS’s as well.

As I read above-linked blog post from the CoreOS team, I found myself agreeing with them more than I expected to. I’m a big fan of Fig, am quite pleased that Orchard was acquired by Docker and that development will continue, but the news that fig would henceforth be built in to Docker itself was a little troubling.

The common Unix-ism is to “do one thing and do it well.” In fact, the entire idea behind containers is that they should do one thing, and do it well. Our production stack has one specific container that runs our app, another that runs nginx, and one last one that handles service discovery. Each container does one thing. Hopefully, it does it well. When it does not, I just have to investigate that one container.

Docker is diverging from that maxim. /usr/bin/docker is your client for interacting with the Docker Hub. It’s your tool for managing running containers. It’s your tool for managing your local library of images. It’s your tool for building new images. Soon, it will be your tool managing entire stacks of containers monolithically and your tool for deploying to production.

Some of those can arguably be considered part of one same thing that it is doing well, but the path is clearly charted in the other direction. Rocket is designed to counter this an offer an alternative, swinging the pendulum back towards the Way of Unix.

I feel like perhaps I’m starting to swing towards being more beholden to CoreOS than specifically to Docker itself.