Some Thoughts on the Docker-Kubernetes Announcement
Published on 17 Oct 2017 · Filed in Musing · 502 words (estimated 3 minutes to read)Today at DockerCon EU, Docker announced that the next version of Docker (and its upstream open source project, the Moby Project) will feature integration with Kubernetes (see my liveblog of the day 1 general session). Customers will be able to choose whether they leverage Swarm or Kubernetes for container orchestration. In this post, I’ll share a few thoughts on this move by Docker.
First off, you may find it useful to review some details of the announcement via Docker’s blog post.
Done reviewing the announcement? Here are some thoughts; some of them are mine, some of them are from others around the Internet.
- It probably goes without saying that this announcement was largely anticipated (see this TechCrunch article, for example). So while the details of how Docker would go about adding Kubernetes support was not clear, many people expected some form of announcement around Kubernetes at the conference. I’m not sure that folks expected this level of integration, or that the integration would take this particular shape/form.
- In looking back on the announcement and the demos from today’s general session and in thinking about the forces that drove Docker to provide Kubernetes integration, it occurs to me that this almost necessitated the direction/manner of integration. Think about it: had Docker chosen to “separate” Docker and Kubernetes under different software stacks, they would have perpetuated the (perceived) battle between Docker and Kubernetes. However, by positioning Docker “above” Kubernetes, Docker instead emphasizes that the true value of Docker isn’t the runtime (
runCorcontainerD) and it isn’t the orchestration (Swarm and Kubernetes). It is, instead, the developer-friendly workflow, ease of use, and management functionality. It also reinforces Docker as a platform, a message that was definitely hammered home in the general session. - Integrating Kubernetes is, in my opinion, just a continuation of the effort that originated in the spin-out of
runCto the OCI (and later the donation ofcontainerDto the CNCF)—all these steps are necessary to allow Docker to divorce itself from the perception that “Docker == containers”. (VMware faces a similar challenge, in that folks think “VMware == VMs/hypervisor”.) - Naturally, there are questions now regarding what will happen to Swarm. The general consensus (see this post by Nigel Poulton and this post by Laura Frank) is that Swarm—as an orchestration mechanism—isn’t going anywhere anytime soon, and I’d agree with this assessment. At the same time, given the industry momentum around Kubernetes—Rancher’s rebuild on top of Kubernetes is one example, VMware’s joint announcement (with Google and Pivotal) of Pivotal Container Service is another—it’s also fairly apparent that leveraging Kubernetes instead of Swarm is probably a better long-term choice. (It would be interesting to think about how Swarm/SwarmKit might be used to enhance Kubernetes.)
As others have said, this is definitely an interesting time in which to work in the technology field. Look for more liveblogging from DockerCon EU 2017 tomorrow, where I’ll be covering the general session in the morning and as many breakout sessions as I can cram into my schedule.