Most users of containers have Docker Engine in their stack, even if it is just the open source engine. Now that Docker Engine 1.12 comes with built-in orchestration capabilities, we expect future surveys to find a substantial increase in people using some of that capability.
While this gives Docker an edge in many ways, do not misinterpret those “anticipated” findings to mean the company has suddenly cornered the “orchestration market.” As seen in several surveys, including our own, multiple orchestration tools are in being used at the same time, with many planning to continue this practice going forward. In this environment, insight is gained by evaluating which providers are preferred most, and by whom.
Kubernetes is the most used orchestration tool, capturing 43 percent of container users. Twenty-seven percent of all container users say Kubernetes is the container orchestrator they use most often.
The ClusterHQ survey published in June 2016 cleverly asked container users about their tools and infrastructure Then, they asked what is being used most frequently. These questions show substantial differences compared to the “check all that apply” questions in many surveys.
Regarding container orchestrators, Kubernetes is still the most frequently used. Docker Swarm comes in second, but two-thirds of its users say it is the orchestrator used most frequently, which is a tad better than Kubernetes. AWS ECS didn’t fare as well, as 52 percent respondents citing it claimed to use it most often. It is quite likely that anyone that uses AWS ECS knows it has orchestration capabilities but when push comes to shove this is not what they tend to use.
It appears that Mesos falls into that category, as only 39 percent of those using Mesos said it was their primary orchestration tool. Many of the offerings in the “other” category were not primary tools being used.
While above chart is fascinating, for now picking a winner is a fool’s errand. It an open question if two years from now there will even be a container orchestration market. Orchestration functionality can be disaggregated into its parts (e.g., cluster management, scheduling, service discovery), but as containers move into production, many users prefer a bundled solution.
Bundling some of the functionality into the container itself is one approach. However, orchestration may also become subsumed into a PaaS offering or be included as capability offered by a cloud provider. Wikibon’s Brian Gracely described this option as a container management platform in a recent article. This term is useful because it captures a broader stack of services being deployed together as a stack. Along with workload and company size, the choice of container management platforms is also still affected by the cloud(s) being deployed to.
Whether they are called container management platforms, orchestrators, or thingamajigs, there are many available options. Cloud Foundry, OpenStack, Kubernetes, and Docker all offer technologies to manage containers. AWS ECS, Microsoft Azure, Google Cloud Compute, IBM Bluemix, Joyent Triton, and Mesosphere’s DC/OS are just some of the public cloud offerings than can be used.
With many of these clouds technologies being used simultaneously, we wondered to what degree are containers being used on and managed with those solutions? And if most enterprises have multiple clouds (see 2016 State of the Cloud Survey), will we use a third-party cloud orchestration/broker tool, or will we rely on our preferred cloud provider’s management tools?
The ability to migrate applications from cloud to cloud is becoming a requirement. Looking forward, more and more applications will be broken up into microservices distributed to different clouds based on price/performance considerations. According to Adrian Coyler of Accel Partners, most companies are targeting deployments that are capable of being deployed on AWS, another public IaaS, and their private data center. Consequently, vendors are creating orchestration tools that interoperate with multiple clouds.
Of course, just because multiple clouds are in use does not mean that one cloud isn’t dominant. The chart below shows that while three-quarters of respondents said they run containers on something besides AWS, Google or an internal data center. However, when push comes to shove, AWS and internal data centers are by far the venue where containers are deployed most frequently.
Everyone who said Kubernetes is the tool they use most also said that Google Compute Engine was the infrastructure they use most. AWS also has it own management platform within its ECS offering, but its customers have not adopted it as much. Of those that deploy containers to AWS most frequently, 25 percent say they use the company’s CaaS as the primary orchestration tool.
Docker Swarm did particularly well among AWS users, possibly due to the size of the deployments. As more AWS container deployments move to away from being on top of VMs, we expect to see a continued uptake of ECS, possibly even to the detriment Kubernetes and Docker. Looking outside the public cloud, internally developed tools beat out Kubernetes as the container management tool of choice. While Kubernetes wants to dominate this field, Docker Datacenter, which wasn’t included in the survey questionnaire, is just one of many on-premise offerings that will compete as well.
With multiple clouds in use, where will most container workloads run? Which providers will be used mostly for cloud bursting or negotiation leverage with another IaaS? The New Stack will leave it to others to determine performance metrics and benchmarks for distributing containerized applications across multiple clouds. Although a Cloud Foundry survey found a preference for bundled container solutions from cloud and/or cloud provider, we wonder how strong that preference is. In the future, we plan to look at how pricing and licensing can impact decisions to deploy to a specific cloud or with a particular orchestration tool.
Feature image via Pixabay.