Why I love containerd…and Docker!

I talk a lot about containerd. I write blog posts about it, speak at conferences about it, give introductory presentations internally at IBM about it and tweet (maybe too much) about it. Due to my role at IBM, I’ve helped IBM’s public cloud Kubernetes service, IKS, start a migration to use containerd as the CRI runtime in recent releases and similarly helped IBM Cloud Private (our on-premises cloud offering) offer containerd as a tech preview in the past two releases. Given that backdrop of activity and the communities I participate in, I obviously hear a lot of chatter about replacing Docker with {fill in the blank}. Given my containerd resume, you might assume that I always think replacing Docker is the right step for anyone working with container runtimes.

Replace Docker!? or “Choose The Right Tool For The Job”

Maybe due to historic frustrations and/or differences of opinion across the container runtime space, some have failed to see that picking the right tool for the job is just as valuable in this context as it is in any other. There have definitely been “party lines” drawn in some circles based on vendor-affiliation, or some basing decisions off the latest arguments on HackerNews. But, let’s ignore that (which, I’ll admit, is good advice generally!) and look at what we are talking about when we compare the Docker toolset to any of rkt, cri-o, containerd, or any other runtime alternative.

This graph shows a sampling of features you might expect or want from a container platform. You can see clearly that containerd contains only a fraction of the capabilities of either the Docker Desktop stack or the pure Docker engine itself. As a [potentially poor] analogy this is like saying I can take away the IDE that my development team uses and provide them with /usr/bin/gcc as a drop-in replacement. You might ask: “well then why use containerd?” Because operationally, containerd makes perfect sense as an implementer of the CRI API from Kubernetes, and as a lower layer life-cycle manager under the feature-rich Docker offerings shown above.

Docker is More Than a Container Runtime

To take this same comparison, but look through the lens of open source, let’s take a look at the number of open source projects that are involved in a Docker Desktop installation on macOS:

• opencontainers/runc (OCI)
• containerd/containerd (CNCF)
• moby/moby
• docker/cli
• moby/buildkit
• linuxkit/linuxkit
• docker/compose
• kubernetes/kubernetes (CNCF)
• docker/libnetwork
• containernetworking/cni (CNCF)
• docker/machine
• theupdateframework/notary (CNCF)
• …and more (VPNKit, DataKit, etc.)

Docker, the company, has taken these components–many of them written and maintained over the years by Docker employees–and have created a self-contained developer environment in a freely available product with everything built-in and working out of the box! Yes, you can replace this with your own created stack, utilizing much of the same open source. This will be hard work, but is fully possible. You may also find other answers for some of your needs, and simply use a container runtime if you have other infrastructure to handle the rest of this cloud native stack. This is an amazing offering, supported and updated regularly for free by the same team that brought you the addictively simple and powerful docker workflow over four years ago. I use it on a daily basis because it just works. And based on Docker’s statistical information, this free product is being used by millions of developers worldwide today.

Docker in the Enterprise

Beyond this desktop stack, Docker has continued to develop an enterprise product that, again, combines a significant number of open source projects, including their own, as a commercial offering. As is normal for any revenue-generating business that has grown up from an initial open source project, Docker, Inc. has had to step through the usual land mines of open source vs. product delineation, and in my opinion have done a good job of maintaining a strong commitment to open source. The Docker engine core is still publicly managed as an open source project on GitHub, and the output of that effort (the community edition) has remained free and without any entanglements to require being a customer of Docker, the company. Those of us who have been around open source for the last decade plus have seen much, much worse. In contrast, Docker has in my opinion dealt with the complex situation of product, revenue pressures, and open source in a reasoned way, introducing the Moby project and many “Kits” along the way to spin out innovation beyond their walls. Some of these–like LinuxKit and BuildKit–have caught the imagination of many well outside the usual Docker circles, and have proven useful to both Docker’s products as well as the open source community at large. In very recent news, Docker has some bragging rights around this enterprise platform as Forrester Research has named them the leader in the enterprise container platform space. While you can bet we at IBM are working to improve and compete with our platform offering here (and we can expect the same from Red Hat, Pivotal, and others) today is a day to recognize Docker has had early success building a competitive platform atop the open source underpinnings.

It’s Docker AND Containerd

So why take the time to write out these thoughts? For one, I want to clarify for my readers the “why” of my current operational focus on containerd. I want containerd to be the best possible core, secure, and stable container runtime for both Docker’s stack, the Kubernetes community, and many additional projects which are finding value in our containerd API and codebase. Secondly, for those trying to understand the choices they have in the container runtime space, I think it is important for people to think through sometimes emotionally-driven responses that ignore the reality of what it means to switch to an alternative.

Finally, I’m about to kick off a series here on my personal blog giving practical migration steps when switching from Docker to containerd as the CRI runtime underneath Kubernetes. As IBM Cloud, GKE, and potentially more public managed Kubernetes offerings switch the CRI-enabled runtime from Docker to containerd, there are a set of learnings I would like to share to help vendors and users through this transition. As I do that, it may appear to some that this is a “Docker versus containerd” discussion rather than a “Docker and containerd” discussion. Hopefully from this post you can see my perspective on these issues, and the fact that I find it totally reasonable to love containerd…and Docker!

Postscript

If you want to talk more about this topic in person, and are attending Open Source Summit next week in Edinburgh, Scotland (October 2018) check out the Docker Edinburgh meetup on Monday evening where I will be talking about this specifically, or catch my talk (also on Monday) at the conference and catch me afterward.

Thanks to draft reviewers who made this post 100x better: Bret Fisher, Laura Frank Tacho, and Jenny Burcio