Docker loses its first-mover advantage to Kubernetes - now what?

A funny thing happened on the way to Docker, the company, dominating a new era of container-based applications. Its core technology became a commodity that's supported on every major operating system and cloud service.

Docker, the technology, was developed by a long-forgotten PaaS vendor that evolved into Docker the company, and encouraged the platform's proliferation by open sourcing the container image, format and runtime engine.

The company subsequently gave the technology to the Linux Foundation to establish the Open Container Standard (OCI). By that point, Docker realized that platform business success relies on network effects: the more people using the product, the more valuable it becomes to everyone and the more money to be made by selling products built on the platform.

As Docker's former CEO, Ben Golub, put it in announcing the standards project,

This effort will allow the ecosystem as a whole to focus on innovation at the layers that matter, rather than wasting time fighting a low level standards war … [Users] will benefit by having the industry focus on innovating and competing at the levels that truly make a difference.  To use an old analogy, why argue about the width of train tracks, when you can worry about laying track and building the best possible engines?

In further rationalizing standardizing the low-level container technology, Golub wrote that the company would focus on a "well-integrated tool chain for developers" and that it was "purposely not trying to standardize the many things which are in areas where there is still a diversity of opinions and approaches."

Although the toolchain and container ecosystem has many elements, the cluster manager cum orchestration controller has emerged as the most important.

Docker's Swarm, has won plaudits for its integration and ease of use, but its serious shortcomings in scaling to large production workloads and other technical, compatibility and reliability problems made it vulnerable to competition.

Leave it to Google, the technology Behemoth with more container expertise than any organization on the planet, to supply the most compelling alternative, Kubernetes.

Two years after open sourcing the software and donating it to a new Cloud Native Computing Foundation (CNCF), Kubernetes (aka K8s to developers) has become the de facto standard container management and orchestration tool.

The latest evidence of Kubernetes' dominance came with the capitulation of an early competitor and infrastructure-as-code pioneer Mesosphere when it announced that its data center OS (DC/OS), which has its own orchestration software, Marathon, would now support Kubernetes as well. The company sees that, like the container image and runtime, orchestration has also become a standard commodity and that Mesosphere's future lies in enabling "enterprise operations teams to deliver a public cloud-like 'Containers-as-a-Service' experience."

K8s' dominance - the handwriting has been on the wall

For those working in or following container technology, the emergence of Kubernetes as the standard workload orchestration platform is no surprise as the software has been winning developer mindshare, garnering endorsements and accumulating support from all the major cloud container services.

K8s is one of the most active open source projects and as CNCF's Executive Director puts it,

...one of the fastest moving projects in the history of open source.

Data from container usage surveys is noisy and inconsistent, primarily due to the relatively small sample set of users and methodological differences. However most results show growing interest in orchestration platforms. For example, Datadog, a provider of application monitoring software, found that 40% of its customers running containers use an orchestration system, primarily AWS ECS and Kubernetes.

Likewise, both ClusterHQ and Portworx, which each develop containerized data repositories, show Kubernetes to be the most popular orchestration tool. Adding DC/OS to the list (which hadn't announced Kubernetes support when the report was written) means that seven of the nine products profiled in Gartner's guide for container management software use Kubernetes for orchestration and scheduling.

This assessment from the recent Cloud Foundry container survey captures the situation,

Regardless of the data, there is a growing consensus in the tech community that Kubernetes adoption is indeed on the rise, displacing both Mesos and Docker Swarm among self-managed container orchestration tools. If we look at secondary metrics, such as Google Trends, as any indication, interest in Kubernetes has increased by nearly 200 percent in a year, while Docker Swarm’s has increased by 66 percent and Mesos by zero percent.

Cloud Foundry uses the caveat "self-managed", but I hasten to note that each of the three major cloud platforms, AWS, Azure and Google Cloud, supports Kubernetes and although it's still a DIY operation on AWS, there are rumors that it may integrate Kubernetes into ECS in the future. Keep an eye out for an announcement in a couple of months at re:Invent.

Why does it matter?

Focusing on one component of container infrastructure might seem like inside baseball to non-specialists and business managers that just want to deploy and use applications. However having a standard, consistent automation and scheduling platform is critical to achieving the holy grail of container advocates: application portability across private and public clouds.

If you use one set of deployment and management scripts when running on premise, another when using AWS ECS and yet another on Azure or Google Cloud, it introduces the same sort of administrative friction that hampers moving VMs between private VMware and public EC2 environments.

The importance of cross-platform portability is underscored by the realization that according to IDC, the majority of enterprise containers will be used to run existing applications through at least 2020 as IT organizations use containers to handle application packaging and management that was previously done at the VM layer.

Furthermore, as IDC Research Manager Gary Chen said during a presentation at VMworld

...container customers want a hybrid deployment model with common management plane.

Increasingly, that container deployment and management platform looks like Kubernetes, which Chen estimates has more than three-quarters of the market.

As I discussed last week, the goal of multi-cloud application portability was the motivation behind VMware's work with Google and sister company, Pivotal to develop the Pivotal Container Service (PKS).

Using Kubernetes as the management plane allows PKS, which can run atop legacy vSphere servers, to seamlessly migrate containerized workloads to Google Cloud's GKE service.

My take

Standardizing higher layers of the container ecosystem will increase adoption, improve both operational and developer efficiency and ultimately lead to more innovative container services and use cases.

As I detailed in discussing the intrinsic benefits of higher level cloud services vis-a-vis traditional VM and storage infrastructure, the proven way of creating technological value is

...is by moving to higher levels of abstraction where you’re more concerned with business services and application features than infrastructure implementation and operational details.

Standardizing the container management and orchestration layer is just the latest example of moving up the software version of Maslow's hierarchy of needs and a demonstration of containerization's rapid evolution as it transforms from a niche technology for savvy developers to mainstream enterprise application platform.

Orchestration is just the start since one look at the Cloud Native Landscape Project's product taxonomy shows a mishmash of commercial products and open source projects that are sure to strike terror in any IT systems designer and cloud developer trying to assemble the tools necessary to build and deploy cloud native applications.

While such diversity is a sign of vigorous innovation, there are obvious areas in the runtime and orchestration and management layers ripe for standardization. With Kubernetes owning the orchestration category, high on my list would be the container cum microservice registry and discovery, along with service and API management and gateways.

It will be interesting to watch the development of various projects in these areas, such as Kong (API, service management) and CoreDNS (service discovery) for signs that developers and vendors are coalescing around a preferred platform and turning it into a de facto standard.