Can rkt+kubernetes provide a real alternative to Docker?

Published: by

Last week in LinuxCon/ContainerCon Berlin, I attended a presentation by Luca Bruno of CoreOS, where he described how kubernetes, the most popular container orchestration and scheduling service, and rkt integrate. As part of the presentation, Luca delved into the rkt architecture.

For those unaware - there are many, which is a major part of the problem - rkt (pronounced "rocket", as in this) is CoreOS's container management implementation. Nowadays, almost everyone who thinks containers, thinks "Docker". Even Joyent's Triton, while it uses SmartOS (a variant of Illumos, derived in turn from Solaris), has adopted Docker's image format and API. You run containers on Triton by calling "docker run", just pointing it at Triton URLs, rather than docker daemons.

I was impressed with how far CoreOS had come. I was convinced late last year that they had quietly abandoned the rkt effort in the face of the Docker steamroller. Clearly, they quietly plowed ahead, making significant advances.

As I was listening to Luca's enjoyable presentation, the following thoughts came to mind:

  1. Docker Inc., in its search for revenue via customer capture, has expanded into the terrain of its ecosystems partners, including InfraKit (watch out Chef/Ansible/etc.) and Swarm (kubernetes). Those partners must view it as a threat. One person called it, "Docker's IE moment," referring to Microsoft's attack on its software provider ecosystem when it integrated IE into Windows.
  2. Docker's API, as good as it is, is very rarely used. With the exception of a developer running an instance manually, usually locally but sometimes on a cloud server, almost no one uses the docker remote API for real management. Almost all of the orchestration and scheduling systems use local agents: kubernetes runs kubelet on each node, Rancher's Cattle runs rancher agent, etc.
  3. Docker is really easy to use locally, whether starting up a single container or using compose to build an app of multiple parts. Compose doesn't work well for distributed production apps, but that is what kubernetes (and Swarm and Cattle) are there for.

As these went through my mind, I began to wonder if the backers of rkt+kubernetes intend to use rkt+kubernetes as a head-on alternative to Docker.

So... what would it take for rkt+kubernetes (or, as Luca called it, "rktnetes" pronounced "rocketnetes") to present a viable alternative to Docker?

Ease Of Use

As described above, Docker is incredibly easy for developers to use on all three platforms - Linux, Mac and Windows - especially with the latest Docker for Mac/Windows releases. rkt, on the other hand, requires launching a VM using Vagrant, which means more work and installation, which slows the process down, which.... (you get the picture). For rkt to be a serious alternative, it must be as easy to use as Docker for developers.

Sure, in theory, it is possible to use Docker in development and rkt in production, but that is unlikely unless rkt provides some 10x advantage in production. Most companies prefer to keep things simple, and "one tool for running containers everywhere" is, well, simple. Even a company willing to make the change recognizes that the run-time parameters are different (even if rkt supports Docker image format) and the "works for me" problem can return, or at least be perceived to do so (which is as important as the reality).

Docker made headway because it won over developers, then operations and IT types.

At the same time, kubernetes is not as easy to use and has a significant learning curve. To some degree, its power and flexibility once in use make it harder to get to usage. That may (or may not) be fine for an orchestrated complex production deployment; it will not fly on a developer's laptop or DigitalOcean droplet.

To their credit, the kubernetes team has released minikube, intended to make deployments easier. We will see how well it does. In the meantime, developers by the thousands learn how to do "docker run" and "docker-compose run" every day.

So:

  1. Starting and running containers must be made much easier.
  2. Starting and running container compositions must be made much easier.

Killer Capabilities

However, even if rkt+kubernetes manage to equal docker in ease-of-use and feature set, they still will just be playing catch-up, which is not a good game to play (ask AMD). In order to win over developers and systems engineers, rkt+kubernetes must be as easy to use as Docker and it must offer some unique capability that is not offered by Docker. Preferably, it cannot be offered by Docker without great difficulty due to some inherent market, corporate or technology architecture structure.

It needs to be something that is  inherently doable, even natural, due to rkt's design, yet difficult due to Docker's design. The goal would be to make Docker play challenging catch-up.

What would such a feature or capability set be? I have some early ideas, but that is the job of CoreOS's (or Google's or CNCF's) product managers to figure out. That is what they pay them for.

Why Do I Want It?

I love Docker and CoreOS. I use their products on a regular basis. They have made my life, and those of many clients and colleagues, immensely easier. I have met people at both companies and respect their professional skills.

Even more than any one product or company, however, I do love competition. It benefits customers primarily, but even the competitors themselves are driven to better services and products, and hence profits.

I want rkt+kubernetes (or some other combination) to provide a serious, viable alternative to Docker to benefit me, my clients (current and future), my colleagues, all technology firms and IT departments, and especially to benefit Docker, CoreOS and Kubernetes themselves.