Docker and Kubernetes are undoubtedly the biggest names in Cloud Native infrastructure right now. But: are they competing technologies, or complementary ones? Do we need to worry about joining the right side? Is there risk here for enterprises, or is the war already won? If so, who won it?
Some context for this query is in order. Three years ago, war was raging inside the data centre. By introducing a whole new way of packaging and running applications called "containers," Docker created the Cloud Native movement. Of course other companies quickly began producing rival container engines to compete with Docker. Who was going to win?
As if the tournament of container systems was not enough, Docker had to fight another, simultaneous, battle. Once containers and container packaging arrived, the obvious next killer app had to be scheduling and orchestrating them. Docker introduced its own Swarm scheduler, which jousted with rival tools from Google (Kubernetes), Mesos (Mesosphere), Nomad (Hashicorp) and a hosted solution from AWS (ECS).
These wars were a risky time for an enterprise wanting to go Cloud Native. First, which platform and tooling to choose? And, once chosen, what if it ultimately lost out to the competition and disappeared? The switching costs for all of these products was very high, so the cost of making the wrong choice would be significant. Unfortunately, while so many contenders vied for primacy in such an emergent sector, the likelihood of making that wrong choice was dangerously high.
So what happened? Who won? Well, both wars got completely and soundly won -- and by different combatants.
Docker won a decisive victory in the container engine war. There is one container engine and they are it.
Kubernetes, which was finally released by Google as its own open source entity, has won the scheduler wars. There may yet be a few skirmishers about, but Kubernetes is basically THE orchestrator.
The final result is that any Cloud Native system is likely to utilize Docker as the container engine and Kubernetes as the orchestrator. The two have effectively become complimentary: Shoes and socks. Bows and arrows. Impossible to think of one without the other.
Does this mean we have no decisions left to make?
Unfortunately things are not yet completely simple and decided. Yes, there are still decisions to make, with new factors which must now be considered. Looking over the current container landscape we still see all kinds of competitors.
First, a large number of container platform products designed to abstract the orchestrator and container engine away from you. Among these are Docker EE, DC/OS from Mesos and OpenShift from Redhat.
Second, there are now managed container services from many of the original punters, like EKS from Amazon, Google’s GKE, and Rancher Lab’s offerings. In addition we've also got newcomer offerings like AKS from Microsoft and Cisco’s Container Platform.
So, that sounds like we have even more options, and even more work to do when choosing our Cloud Native platform and services.
No, The Situation Has Changed
While it is true that there are even more platforms to choose between now than three years ago, the situation is actually very different now. All of the current platforms are based on Kubernetes. This alone makes them far more similar than the three pioneering orchestration options -- Kubernetes, Mesos and Swarm -- were in the past. Today’s choices may vary somewhat on small details, like slightly different costs, approaches to security, operational complexity, etc. Fundamentally, though, they are all pretty similar under the hood. This means one big important change: the switching cost is vastly less.
So, for example, imagine you pick EKS to start out on. One year down the line you decide you'd like to manage things yourself and want to move to OpenShift. No problem. The transition costs are not zero, but they are also not severe. You can afford to change your mind. You are not held prisoner with your platform decision by fear of retooling costs.
That said, it is important to recognize that there can be additional costs in changing between platforms when that means moving away from nonstandard or proprietary tools bundled with the original choice. Services that are simple to use on the public cloud service you started with may not be so simple, or even available at all, on others. A significant example of this is services like DynamoDB, Amazon’s proprietary database service; while easily consumable on AWS, it can only be used there. Same with OpenShift’s Source to Image tool for creating Docker images.
Basically, to reduce the cost (risk) of future migration it is advisable to use, from the start, standard tools with standard formats. Such as the native Kubernetes API, or tools like Istio (which sits on top of K8s, and seems to be leading the service mesh market) that work on all the platforms.
Other than that you should be fine. You can move. The cost of being wrong has been dramatically reduced.
This is such great news for enterprises that we shall say it again: You can move! In the early days, there used to be a very difficult decision to make. Should you move quickly and risk getting locked into what could become a dead end technology...Or wait until it’s safe, but suffer opportunity costs?
No more tradeoffs. Now that the risks are reduced, there is no need to wait any more. Pick your platform!
Looking for a new challenge? We're hiring!
Previous article
