Docker gets pragmatic, embraces Kubernetes

So it happened today. Docker announced support for Kubernetes, making the container orchestration platform a full citizen alongside Docker Swarm as a deployment target. The keynote demo was pretty sweet – showing how a Docker user really didn’t need to make a choice any more about which orchestrator to use.

#Docker Compose deploy to #Kubernetes “docker stack deploy —compose-file=<> app” same tool chain, deploy, scale, update, rollback #DockerCon pic.twitter.com/d89NJHLPl8

— Arun Gupta (@arungupta) October 17, 2017

As Solomon Hykes said:

“It’s not a fork, it’s not a wrapper, it’s not a half integration shim thing. it’s full support”

Docker’s decision to offer native support for Kubernetes makes obvious sense from both a business and a technical perspective.

Kubernetes is crushing it – it is now the defacto standard for container orchestration, given support from pretty much the entire vendor industry from Amazon Web Services, to IBM, Google, Microsoft, Oracle, Pivotal and Red Hat. Given that Kubernetes is the platform being chosen for deployment and operations it is also where the money is going to flow. Docker couldn’t afford to shut itself from the business opportunity. It has to be galling to be the company that kicked off the container revolution, only to see Red Hat emerge as a competitor with OpenShift, because of its Kubernetes story, packaging expertise and customer footprint. Latterly Pivotal has thrown its hat into the ring with Pivotal Kubernetes Services.

Meanwhile, technically speaking, integration was never going to be too painful. Kubernetes and Swarm are cousins, if not siblings. As Hykes said in a session after the keynote:

“Orchestration is a commodity, over time… as we expect it to be. My observation is that all orchestrators look more and more alike. the only two that matter are Swarm and Kubernetes. Over time no one will care which orchestrator is winning”

Sounds a lot like convergence doesn’t it? Docker’s decision makes a great deal of sense. It’s easy to view embracing Kubernetes support as a zero sum game, where Docker loses because Kubernetes wins. I am not sure that makes sense.

It’s Docker’s job to do the best job of packaging container stacks to make them easily consumable, even if the technology comes from outside. The last thing prospective customers want to see are religious wars. As Brendan Burns, one of the original creators of Kubernetes, now at Microsoft Azure, said in the hallway after the event, Docker makes tools that people like to use. Tim Hockin, Principal SW Eng, Kubernetes & Google Container Engine, agreed that what matters was user experience. And whatever your opinion of Docker, you can’t deny it’s very good at creating tools that developers like. Before Docker, containers were painful. Now – it’s a new industry.

But it’s also a community. It was very very clear talking to Burns and Hockin the high regard they have for Docker and Hykes. They weren’t crowing at all, but rather happy that a point of contention had been taken off the table.

“@containerd moving from BDFL to community-based governance” by @thockin at #DockerCon “exciting times for boring infrastructure” pic.twitter.com/UNEprj2vG8

— Arun Gupta (@arungupta) October 17, 2017

Docker’s focus should absolutely be on creating tools that paying customers want to use, not trying to outflank Kubernetes. And today it announced that it’s doing exactly that. I will be saying more tomorrow about paying customers when I discuss Docker’s Modernize Traditional apps (MTA) program and news from the day two keynote.

full disclosure: AWS, Docker, Google Cloud Platform, IBM, Microsoft, Oracle, Pivotal, Red Hat are all RedMonk clients.