Docker used the picturesque setting of its Copenhagen DockerCon event to announce Kubernetes support for both, Docker Enterprise Edition and Docker Community Edition. The company plans to deliver betas for end of 2017.
Docker’s Critical Challenge: Monetize Its Popularity
After raising $242M in funding with the latest round of $62M closing this month, Docker is feeling the pressure to start making some money or at least acquire paying customers at a faster pace. The replacement of CEO Ben Golub with Steve Singh in May, a more ‘traditional’ choice was a clear sign of the investors running out of patience with the company celebrating the market share of its container engine without a clear path to monetizing it. As Docker is not able to charge money for licensing its container engine (containers are part of any Linux distribution today, and have been built into the Linux OS long before Docker added its secret sauce to them), the entire story must focus on offering the simplest, most scalable, most flexible, secure and easy to operate container management platform in the market. Docker container management technology must be the clear gold standard for container management as otherwise enterprise customers would have no reason to work with a relatively new startup versus leveraging the enterprise experience of one of the more experienced enterprise vendors such as RedHat, IBM, VMware, Dell EMC or Microsoft. The upcoming Enterprise Management Associates (EMA) research project will examine 18 categories of vendors trying to convince customers of the superiority of their own container management platform.
The Competition Is already there
Microsoft, Amazon, VMware, Dell EMC, RedHat and basically all other major players have rallied behind Kubernetes over the previous 12 months. Therefore, more and more industry observers were scratching their heads wondering when Docker would finally cave and support the most popular and fastest growing container scheduler in the market place. When VMware announced Pivotal Kubernetes Service (PKS) last month at VMworld 2017 in Las Vegas and Amazon announced Kubernetes support right thereafter, there was significant concern regarding Docker exclusively betting on Swarm.
Why Did Docker Refuse the Kubernetes Reality for so Long?
Imagine you are a CIO and your developers are asking for Kubernetes APIs that are widely supported by almost the entire industry. Do you then go and buy the only container management platform that explicitly does not offer the requested APIs? It is unclear how many deals Docker lost because of this, but it is safe to assume that investors were not amused.
Why did Docker hold out for so long, insisting that Swarm was the right way forward? One of the key facts of developing commercial software solutions is that it is always hard letting someone else into your stack. By definition, you give up some ‘secret sauce’ and some degree of control. However, while Docker has been playing the ‘secret sauce’ card, positioning Swarm as the scheduler of choice by the ‘people who brought you Docker containers,’ the market had already spoken quite a while ago against Swarm and for Kubernetes. Regarding control, you certainly cannot deny that maintaining your own scheduler gives Docker the ultimate degree of flexibility, especially when it comes to ‘custom integrations’ with components that are further up in the stack, such as workflows and policies. However, today’s software marketplace is all about choice and open APIs and once the developers had spoken for Kubernetes, there was no reason to fight an uphill battle to try and force customers into their own scheduler.
How Does the Kubernetes Integration Work: Project Moby
Docker EE's modular architecture enables the platform integrate with the Kubernetes APIs instead of the Swarm ones. The Moby project, fathered by Kubernetes and Docker, is key for this integration as it provides a set of standardized components for assembling a container platform. The 'containerd' component provides the runtime and image service that can be connected to the Kubernetes CRI (Container Runtime Interface) API, allowing Kubernetes to start scheduling containers. The next assembly of open source Docker will include the integration between CRI-containerd to connect the standard Moby container runtime (containerd) to CRI. Sounds easy, but there will be much regression testing involved to ensure a production ready integration.
In addition to Kubernetes management, Docker EE will offer automated installation for Kubernetes. Docker Swarm will always be installed in parallel, as it also provides security, policy, availability capabilities for the entire container stack, including Kubelets and PODs managed by Kubernetes. Once the Kubernetes integration is available development teams can choose whether to deploy their containerized applications to Swarm or Kubernetes Kubelets.
Market Impact: Positive, but follow-through is needed
Without any doubt, supporting Kubernetes eliminated a key roadblock for Docker’s success. This integration addresses the developer demand for the Kubernetes API and alleviates a good part of the CIO’s concern regarding buying into a proprietary container management stack. To underline this argument, let’s think back to when it became evident that OpenStack running on HP was not the same OpenStack that was running on Rackspace. This revelation made a large dent into the belief that OpenStack might become main stream in the enterprise.
To ultimately be successful Docker needs to follow through on its promise of making the easiest to deploy, manage, and upgrade container platform anywhere. Docker needs to also accept the fact that the wholesale containerization of all enterprise applications typically does not make sense. Let’s remember that we can achieve pretty much the same degree of DevOps automation and a similar degree of application mobility without containers. This means that Docker needs to clearly proof for each application that there is an actual benefit of containerization and that there is no admin overhead or security/compliance challenge that negates this benefit.
The full commitment from Docker to Kubernetes came later than we would have hoped. But the container management market is still in its infancy and I believe that it is not too late for a clear value-focused strategy that aims at monetizing Docker EE container management to succeed. Key will be to give customers a reason to “go with the startup instead of the established enterprise.”
Stay tuned as we will shortly examine Docker’s propagation of a ‘lift & shift’ approach to containerizing enterprise applications. In addition to the lack of Kubernetes support this has been a long time point of concern, as this strategy seems to miss the realities of the market place.