Within a timeframe of only 6 weeks, both Docker and Mesosphere both announced Kubernetes support for their container management platforms (Mesosphere and Docker Enterprise Edition). This ‘officially’ concludes the container scheduling contest and rings in the critical phase of the much more important and lucrative container management bake off.
[embed width="500"] https://youtu.be/x4Jx8-uOAwQ [/embed]
In a Nutshell: What Does a Container Orchestrator Do?
In short, a container orchestrator absorbs compute, network, and storage resources and leverages them to deploy, load balance, scale, and protect a container cluster based on policy rules. Therefore, the container orchestrator must take care of the following key tasks:
- Deploy, delete, start, stop containers
- Attach storage volumes to containers
- Enforce isolation and security
- Provide networking services required for load balancing, availability, and scalability of apps
Of course, this is a dramatically simplified description of what’s required from a container orchestrator, but it is sufficient for the string of arguments laid out in this post.
And the Winner Is: Kubernetes
Kubernetes -Greek for Helmsman- came out of Google in summer of 2014. Google uses Kubernetes for its Google Container Engine CaaS offering, but today all major players in the industry (RedHat, VMware, IBM, Microsoft, Amazon, and now Docker) support Kubernetes. Google (34%) and Red Hat (15%) are the largest contributors to the Kubernetes open source project today.
Why Kubernetes Won?
Kubernetes won the scheduler race because of the following key factors, which are mostly non-technical:
- Aura of scalability: As Kubernetes came out of Google, it automatically came with an auro of scalability. Google fostered this auro by offering its own Google Container Engine service based on Kubernetes. From a technology perspective, you could argue that Kubernetes offers better inherent abstraction as Pods (collections of containers that contribute to a specific app or service), not servers, are the unit of scheduling.
- Aura of openness: Google is the only one of the three vendors that does not sell software. This means that customers do not need to worry about parts of Kubernetes becoming closed source and being wrapped into a commercial product.
- More enterprise features built in: The more enterprise features, such as auto-scaling, load-balancing, and secrets-management come with the open source scheduler, the less vendor-lock in there is. This does not mean that customers will manage their own Kubernetes without leveraging a commercial management platform, but it does mean that the more capabilities the open source scheduler has already built in, the more capabilities the customer can move to a different management vendor or CaaS provider without requiring professional services.
Kubernetes Won: How Does it Affect the Customer
The fact that Kubernetes won the container orchestration race would only matter if…
- ...customers had a straight path to using Kubernetes as their stand alone container management system, without spending money on Docker Enterprise Edition, RedHat OpenShift, VMware PKS, IBM Bluemix or any of the other container management platforms. Today, going straight to Kubernetes would not make sense as any savings in license cost would be vastly exceeded by the additional cost for obtaining the staff skills to deploy and operate Kubernetes would.
- ...docker and Mesosphere had been able to leverage their respective schedulers as a competitive advantage for their platforms. With exceptions, this was not the case in the eyes of the customer. If anything, both companies stopped fighting the inevitable win of Kubernetes over their own schedulers too late, unnecessarily losing deals.
Therefore, the standardization on Kubernetes should not have a significant effect on the container management marketplace.
In my next post, we will explore which container management solutions there are on the market place. Of course the upcoming EMA Container Management Buyer’s Guide will drill much deeper into this topic.