Container Orchestration Wars Start to Heat Up
When Docker is clearly the dominant instance of containers the debate over how containers should be managed is now just only beginning. At present, there are arguably four leading orchestration platform most commonly employed for managing containers. The first is the Kubernetes framework originally developed by Google. The second is the Amazon EC2 Container Service. The third is the Apache Mesos project support by Mesosphere. The fourth is Swarm from Docker Inc.
As part of an effort to convince IT organizations that there is a fundamental difference between an orchestration framework natively designed for Docker versus Kubernetes specifically, Docker this week make available the results of a set of tests conducted by a technology consultant it contracted to prove the scalability of Swarm versus Kubernetes. The goal was to test the performance of both platforms while running 30,000 containers across 1,000 node clusters with an eye towards measuring container startup time and system responsiveness under load.
Docker claims the results show that Swarm is on average 5 times faster than Kubernetes in terms container startup time and seven times faster in delivering operational insights necessary to run a cluster at scale in production. David Messina, vice president of marketing for Docker, says that matters because container startup time wreaks havoc on distributed applications that need near real-time responsiveness. Even in cases where real-time responsiveness isn’t needed, Messina says taking all that extra time to bring up infrastructure is painful for IT operations teams.
As is always the case with these tests actual individual mileage when running any of the leading container management frameworks will vary. But the fact that Docker is going to the trouble of conducting these tests does indicate there is a fair amount of concern over whether Docker can dominate both the container itself and the framework being used to manage them. Messina says the real key difference between Swam and other frameworks is that not only is Swarm more efficient, Docker container applications have to be refactored to work with other frameworks. That not only adds additional overhead to the development process; it runs counter to the highly integrated DevOps environment that many IT organizations are trying to foster, says Messina. Swam, meanwhile, employs native Docker CLI and APIs, which enables applications to be consistently deployed regardless of where applications actually wind up running.
In addition, Messina notes that Kubernetes was designed by Google engineers that have ready access to all the compute resources they need. In contrast, Messina says Swarm was designed with the needs of IT administrators that are typically trying to maximize the utilization of a limited set of IT infrastructure resources.
But while all that may be true many IT organizations are hesitant to be beholden to Docker for both the containers and the orchestration framework needed to run them. The management tools surrounding Docker are clearly crucial to the Docker Inc. business model. But after many IT organizations relied on the same vendor for virtual machines and the tools needed to manage them, many of those IT organizations are understandably concerned about once again getting locked into a single vendor.
