Was it any surprise that Docker announced support for Kubernetes?
Docker made the decision to wait until it had fully integrated the Kubernetes open source container orchestration engine before making its announcement at DockerCon Europe. Instead of building a narrative over the past several months about embracing Kubernetes, Docker instead chose to develop the integration internally and announce it all at once. Interesting to note that Docker did something similar in 2016 when announcing at DockerCon in Seattle its built-in orchestration capabilities using Docker Swarm in Docker 1.12. There had been little announced about the deep Swarm integration prior to the conference.
With Swarm, Docker Engine allows developers to orchestrate the operation of complex containerized applications using the same command-line structure and syntax that they are familiar with when using Docker containers. This is also what Kubernetes offers. Developed by Google, Kubernetes is now managed as an open source project by the Cloud Native Computing Foundation.
Docker orchestration capabilities followed its “batteries included but replaceable” model. The company included Swarm in the Docker Engine, but users could switch out Swarm to use Kubernetes or an alternative orchestrator. The Docker orchestration capabilities were opt-in; they had to be activated by the user. Though not opting in could lead to backward compatibility issues down the road. Docker’s decision led to major philosophical differences between Docker and key players in the community.
Swelling support for Swarm did not come after DockerCon in Seattle. What we did see instead was a big rush of support for Kubernetes and boiling concerns about Docker’s path to develop using an inward approach. The community rushed to provide deeper support for Kubernetes and container engine alternatives such as CRI-O, which last week celebrated its 1.0 release. Today, the Kubernetes platform has almost universal support. Docker had no choice but to support Kubernetes.
There’s a lot of upside for Docker with Kubernetes support.
“Kubernetes is fast gaining mindshare, driven by the declarative approach it offers in the automation of container native infrastructure,” wrote Krishnan Subramanian, our technical editor for The New Stack’s Kubernetes ebook series. Between the Docker support and Cloud Foundry’s recent adoption of Kubernetes, “There is a high chance that Kubernetes will emerge as a standard in the container orchestration and be a standard component of any developer-centric platform.”
In this light, it makes sense for Docker, now relentlessly pursuing the enterprise market, to embrace an external technology. “It’s Docker’s job to do the best job of packaging container stacks to make them easily consumable, even if the technology comes from outside. The last thing prospective customers want to see are religious wars,” RedMonk analyst James Governor wrote in a blog post.
The fate of Swarm may be another matter. Would it be any surprise if Docker, sometime in the future, retires its Swarm? The company has argued for the security benefits it brings, even when working with Kubernetes, and plans to continue to support Swarm. To what extent is another matter.
DockerCon has historically served as a technical conference and its news about Kubernetes embodied that approach. But it was really more of a conference to discuss its software supply chain. Docker’s decision to support Kubernetes does mean stability for the overall cloud-native ecosystem. With Docker’s support, partners now have one more reason to embrace Kubernetes. It guarantees that Docker releases will be in line with Kubernetes.
Docker’s support simply makes the infrastructure boring. And that’s a good thing.