Docker’s mascot may be a whale, but Kubernetes was the elephant in the room before Dockercon Europe 2017. All three major cloud providers have joined Kubernetes’ hosting open source foundation, the Cloud Native Computing Foundation (CNCF), making the momentum undeniable.
The shift in the industry seemed to leave Docker Swarm on an island. Competitors such as Redhat’s Openshift had long ago adopted Kubernetes and Docker finally boarded the Kubernetes train during Dockercon Europe 2017, announcing an integration with Kubernetes as part of its day one keynote.
Docker has done to containers what Apple did to iPhones. Docker helped bring containers to the mainstream. Since the release of the project, Docker has focused on the developer experience. The base concept is that you can build, ship, and run applications in a standard framework across the industry. In theory, an organization can create a continuous integration and continuous development (CI/CD) process starting from their laptop and move into production.
SEE: Why containers are critical to successful DevOps projects (Tech Pro Research)
One of the first challenges was data center orchestration. Unlike VMware vSphere, very few tools existed to manage workloads in production at scale, and Docker’s primary method to orchestrate containers at data center scale is Docker Swarm.
There’s no shortage of container orchestration solutions. The early leader, Mesosphere, has lost much of its momentum. Docker Swarm is a single vendor’s view of orchestration, but it offers a tight integration with Docker Enterprise Edition (EE). Docker is building a platform with Docker EE that compares to mature projects such as Cloud Foundry. However, as mentioned, the industry has converged on Kubernetes.
According to Docker, Google brings their hyper-scale experience to container orchestration. And the open approach to Kubernetes won over much of the ecosystem to Kubernetes.
Kubernetes has a significant learning curve. Docker’s implementation looks to hide much of the complexity of Kubernetes behind the scenes. The orchestration layer is like a contract between the application developer and operations teams. The API is the language used to translate between the two groups. Swarm and Kubernetes not only use different architectures, but both platforms also use different APIs.
Docker took the approach of providing a design that allows for running both Kubernetes and Swarm within the same cluster. When deploying Swarm, the installer provides an option for installing Kubernetes. If selected, Kubernetes inherits the redundancy design of the Swarm install, while integrating two different approaches to subsystems such as networking.
Ecosystems designed for either orchestrator should still work independently. For example, applications and processes that leverage a native Kubernetes API work directly against a Swarm-deployed instance. Similarly, applications built using a Docker Compose file run natively against Swarm-provided Kubernetes infrastructure.
This brings us to the challenge of resource management. While Swarm and Kubernetes can run on a single host, each orchestrator remains unaware of the other. Each orchestrator assumes 100% use of a single host. For this reason, Docker doesn’t recommend running Kubernetes and Swarm workloads on the same host.
With general availability expected Q1 2018, I don’t believe I’m overstating anything by saying this is a pivotal moment for the container ecosystem. Docker remains critical to the container-based development experience. And by integrating Docker EE with Kubernetes, Docker expands the argument of existing not just as a development platform, but a production-level ecosystem that competes with PaaS offerings.