Docker now includes built-in container orchestration

Container Docker Orchestration CSC Blogs

Docker, the 800-pound gorilla of container technology, has recently added a new and very important trick to its magic act: Orchestration.

For musicians, orchestration means writing music for a particular musical group. For those us in IT, orchestration is the automated installation, coordination and management of complex software systems. We know orchestration best these days from its use in cloud DevOps.

Containers, which use shared operating systems to run server applications, add yet another level of complication to clouds. So besides cloud DevOps programs, such as Ansible, Chef, Puppet, and SaltStack, you also need programs such as Apache Mesos, Google Kubernetes or even Docker’s own Docker Swarm.

Now, Docker has decided that orchestration should be built in to containers. Starting with Docker Engine 1.12, container orchestration will come bundled inside Docker.

Docker’s logic is that this “democratization” of orchestration will make container management much easier.

Specifically, according to Docker:

“Container orchestration is what is needed to transition from deploying containers individually on a single host, to deploying complex multi-container apps on many machines. It requires a distributed platform, independent from infrastructure, that stays online through the entire lifetime of your application, surviving hardware failure and software updates.”

Docker’s orchestration goal follows its “philosophy about containers: No setup, only a small number of simple concepts to learn, and an ‘it just works’ user experience.”

That sounds good. It may very well work well. But, I’m worried.

My concern is that ever since Solomon Hykes founded Docker, its mantra has been “batteries included, but swappable.” What that meant is that while Docker has been adding in more necessary components, such as networking and now orchestration, you can only switch them out for a different technology.

I hope that continues to be the case. I, for example, am very fond of Kubernetes for container orchestration. But, I remember how bitterly Docker fought with CoreOS, a rival container company when it opened its doors.

Last year, Docker sort of, kind of agreed when it helped form the Open Container Initiative (OCI) and the Cloud Native Computing Foundation that Kubernetes would be the default container orchestration tool. I saw Docker’s cool response to Kubernetes as being worrisome. I’d hoped then that the container standardization conflicts would come to a peaceful resolution. I greatly fear I was wrong.

We’ll see what happens next.

RELATED LINKS

Securing the server programs hiding in your Docker containers

One world, one container: Open Container Project

Containers: In the beginning

Comments

  1. James Coulter says:

    I share your concerns, Steven. Docker is running dangerously close to a my-way-or-the-highway attitude, which became apparent to me with this post by Tim Hockin http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html .

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: