Docker’s Killer Feature

In a recent blog post, CoreOS essentially declared war on Docker with the announcement of Rocket, their own rival system. This seems to be the essence of the CoreOS criticism of Docker:

Unfortunately, a simple re-usable component is not how things are playing out. Docker now is building tools for launching cloud servers, systems for clustering, and a wide range of functions: building images, running images, uploading, downloading, and eventually even overlay networking, all compiled into one monolithic binary running primarily as root on your server.

They elaborate:

From a security and composability perspective, the Docker process model – where everything runs through a central daemon – is fundamentally flawed. To "fix" Docker would essentially mean a rewrite of the project, while inheriting all the baggage of the existing implementation.

The problem with this pair of assertions is that they neglect one essential aspect of Docker — one that is arguably its killer feature: its open API. In fact, when we at Joyent first took apart Docker, the robust API came as a pleasant surprise: given that Docker delivers both client-side and server-side software in a single binary, it would not have been a surprise to find that the on-the-wire interface between the two to be unspecified, undocumented and unsupported. To the contrary, we found a solid, well-designed, versioned API (one that probably only comes from the hard-won wisdom of having not done it that way on previous systems).

We were happy to discover this because robust APIs have always been essential for unlocking systems innovation: it is only once interfaces have stabilized that independent implementations can become radically enhanced. This is not unique to software systems: the development of standard gauge was essential to the blossoming of the railroads in the mid-19th century — and (especially apropos) the development of the twistlock by Keith Tantlinger birthed the shipping container revolution over a century later.

Solomon and the Docker crew clearly get this — and it is their API-centric approach that allows them to achieve their stated goals of "batteries included, but removable" and "infrastructure should be pluggable and composable to the extreme." We know that this isn’t mere rhetoric, because we at Joyent are implementing a new Docker API end-point in sdc-docker, our Docker engine for SmartDataCenter, the (open source!) cloud orchestration software that we use to run our own cloud (and make available to others to run theirs). Our implementation is relatively new and rapidly evolving, and while we’ve found some small opportunities for improvement, we know enough to know that Docker’s API is fundamentally sound — which in turn speaks highly of their entire approach. So yes, there are many open questions (especially around network virtualization and persistence), but given the robust community and the API-driven ethos of Docker, we are confident that the Docker ecosystem will continue to expand and flourish — and like the railroad and shipping container revolutions from which Docker draws direct inspiration — unlock innovation and economies-of-scale everywhere!

Post written by Bryan Cantrill