Docker snaps up SocketPlane to fix networking flaws

With Docker 1.5 freshly released, the creators of the software-containerization system are looking to fix its networking issues, which have long been a source of pain and criticism.

The long-term solution may come via an outside company acquisition: SocketPlane, a startup (Q4 2014) that announced plans “to bring software-defined networking to Docker.”

Docker Senior Vice President of Product Scott Johnston explained in a phone call why SocketPlane’s approach attracted Docker’s team. SocketPlane’s methodology, he said, is built on OpenDaylight/Open vSwitch’s network fabric system. The intent is to provide similar overlay networking for Docker containers in a way that can be made pluggable, so implementations can be swapped out as needed.

“From watching the adoption of [Docker] users,” Johnston said, “we realized they wanted a next-generation, more sophisticated networking model that first-gen Docker didn’t provide.”

Make it speedy, make it scale

SocketPlane’s system is a “supersimple, L3-focused network overlay approach” that, in Johnston’s view, is a good complement for the way containers work. For one, such an approach is designed to scale the way containers scale: “In a VM world, you’re dealing with maybe 10 to 100 VMs [on a given host], but you could have thousands or tens of thousands of containers.”

Persistence is another consideration. VMs are stood up for weeks or months on end, Johnston said, while containers may run for only minutes at a time. Consequently, Docker needs a networking solution that respects those behaviors.

SocketPlane is one of numerous projects tackling networking in Docker — both in the way containers talk to the outside world and how they talk to each other. Among those other projects was Google’s Kubernetes, although it offered only so much help with networking. CoreOS, creators of an entire Linux derivative built on containerization technology, created Flannel.

Docker has given each of these projects a nod, but it has held off on making any of them official.

Batteries included, but optional

The ultimate goal is to create a solution along the lines of other “batteries-included, but optional” approaches that populate Docker’s ecosystem. When completed, Docker would ship with a reference implementation of the networking API, but a user could pop in one from another vendor as needed.

“The explicit focus of the SocketPlane team within Docker,” said Docker’s press release, “will be on collaborating with the partner community to complete a rich set of networking APIs that addresses the needs of application developers and network and system administrators alike.”

Johnston emphasized that the point of acquiring SocketPlane was not to crowbar the company’s solution into Docker and be done with it. Rather, Docker wanted the SocketPlane team to come aboard and “lead the conversation.”

“This is not to compete with the ecosystem,” he said, “but to enable the ecosystem.” His words are a nod toward the ongoing criticism that Docker’s focus on providing a complete set of container solutions has stifled competition.

Docker has previously bolstered its work by way of external acquisitions. When the company acquired Orchard, it was both to add the company’s staff and to formally incorporate Orchard’s Fig environment-orchestration tool into the Docker ecosystem. Fig has since become the basis for Docker Compose, part of the trio of tools Docker put out recently to further aid deployment and orchestration.

The newness of the tools and their approach means Docker users will need some time to get their hands dirty with it and see if they — along with the forthcoming networking solution — in fact “provide for a model where competing vendors can work from one standard, while optimizing their own technologies for differentiation,” as Docker’s press note puts it.