ClusterHQ: The Importance of Container Plugins for Extending Docker’s Functionality
A container isn’t a computer. It can be something as simple as a process — coupled with only the resource code and local operating system services needed to make that process operational — supported by an underlying OS. But there’s something else that people still have a difficult time envisioning: Because containers can be networked, so can processes. For the first time, functions can have their own IP addresses.
What’s more, containers can be extensible. This last virtue has been difficult for even Docker, Inc. to fully envision. At the last DockerCon a few weeks ago, developers got their first glimpses of a more fully realized vision for container plugins — functions that can extend the usefulness of containers in standardized, reliable ways. This time, the vision took account of the fact that plugins would need to utilize one another.
Glider Labs Principal Jeff Lindsay explained the new vision to DockerCon attendees this way: “As a systems integrator, we’ve learned that most every custom application has different requirements. Certain domains like storage and networking are really complicated; there’s lots of options … Plugins provide users with choice, freedom and the implementation of underlying storage drivers and other things in Docker.”
The formation a few weeks ago of an Open Container Project (OCP) left many with the impression that, going forward, there would be a single standard not just for container images but also for the emerging ecosystem surrounding them. That impression has faded somewhat in the light of market realities. Still, there was discussion about the idea of a single standard specification for containerization plugins, such as Lindsay described.
ClusterHQ makes a plugin called Flocker that enables the applications running within containers to retain their bindings to external database volumes when those containers get moved within networks. For Flocker to be effective, it needs to be capable of interacting with whatever is handling the networking for those containers, which in a growing number of cases is Weave Net.
For the rapidly growing container ecosystem to work effectively, should the OCP apply itself to the task of standardizing the interface between containers and plugins, for Docker as well as rkt and any other formats? The New Stack sat down with ClusterHQ CEO Mark Davis and CTO Luke Marsden to get their opinions.
Luke Marsden, CTO, ClusterHQ: There will be a big gulf of time between Solomon [Hykes, Docker CTO] stating where we want to be, in terms of interoperable formats and everyone gathering around these new tools, and where we are today. Plugins exist now in Docker 1.7 Experimental, and I think that the investment we’ve made in implementing the volume plugin will be very, very widely applicable to all consumers of Docker.
I also think that, from a strategic perspective, the fact that everyone has made up and everyone is friends again is great, because it means that we can go ahead and build plugins for everything else without fear of retribution.
Mark Davis, CEO, ClusterHQ: Part of what happened with the container format disagreements in the past were, people seeing shortcomings in what existed and saying, “Hey, there’s a better way to do this.” I think the same could apply to plugins. If it turns out that we haven’t gotten plugins right this time, and we don’t make it go where the community wants it to go, then there may be other people who choose to do plugins in a different way. I can imagine that. I think it’s our job to make sure that doesn’t happen.
Competition of ideas is a spectacular thing. Replication of work is a waste of time. So if we have a competition of ideas, and have people come back and say, “Here’s a different, better way to do plugin architecture,” and we can agree to that, that’s a good thing. I personally will be shocked if we don’t learn something about plugins that makes us think, “You know, that thing we did in [Docker] 1.7 Experimental wasn’t perfect; we might want to improve that.” And I think as long as we can do that without having splinter groups, that would be a great thing, right?
Luke Marsden: From a ClusterHQ perspective, we don’t care exactly how plugins work. We’re not the container plugin people. We don’t care about, “Oh, we’re really invested in this particular format of plugin communication.” We just care about the fact that there is a way of extending Docker’s functionality, so that we have a rightful place in the ecosystem. So if the plugin format changes, we’ll adapt to it. The work that we did on plugins was a means to an end, frankly, not just because we thought that Docker should be pluggable.
Scott Fulton, The New Stack: Well, I remember years ago, in the ‘90s, in the early development days of the Web, when Netscape wanted to develop a standard around plugins for the browser, because it saw the future of the development ecosystem being ways to extend the browser to do more things with browsers. Microsoft followed suit, and the whole ActiveX standard came about. We had tugs-of-war about the way that extensibility should be handled on the Web. And a lot of these tugs-of-war culminated in the kind of truce that we see that is the W3C, which is an agreement to keep an open mind and discuss things a lot.
But one of the things I know about the Web is, there’s more discussion than there is action. That’s what I’m worried about here. If there’s one thing worse than replication of work, it’s replication of history.
Mark Davis: Standards bodies in groups like this can be very, very good at slowing things down. I’ve seen companies that have made it their strategy: “I joined the group because my goal is to slow it down.”
If somebody said, “We’re going to create an open standard for a container format for plugins,” we’d probably want to participate. We’re certainly not going to wait for it. We’ve got to build software and ship it, and solve customers’ problems. And ultimately, that’s what’s going to have the weight anyway — what gets adopted.
Scott Fulton: Now that the OCP is a done deal, it’ll be a fixed part of the world, and there will be communication going on between some premiere vendors that all have a stake in the monitoring and management systems they will be building on top of the platform, can you faithfully say that the Docker ecosystem will continue to be led by Docker developers?
Luke Marsden: I think that Docker has a very strong leadership position, and I think that the formation of the OCP actually strengthens their leadership position. And I sensed in the ecosystem, in the last few months, that there were tensions.
So in a sense, if Docker hadn’t stepped up to the plate, then maybe some other vendors would have done it. And the fact that they did step up to the plate meant that they’re stronger for it.
So I see Docker continuing to play a vital role in defining these standards, but doing so in a collaborative way — which, frankly, is what they did with us with volumes plugins. And I think they were very grown-up about it.
CoreOS (the makers of rkt) and Docker are sponsors of The New Stack.
Feature image [left to right]: ClusterHQ CEO Mark Davis and CTO Luke Marsden.
