Docker in Light of the Socketplane Acquisition
This week Docker announced their acquisition of Socketplane, a start-up company working on software defined networking for Docker. In this post I shall say what I think this means for us, for the new Docker seen as a platform, and...
This week Docker announced their acquisition of Socketplane, a start-up company working on software defined networking for Docker. In this post I shall say what I think this means for us, for the new Docker seen as a platform, and for the ecosystem.
Weaveworks support the acquisition of Socketplane by Docker
Let me start by congratulating the whole Socketplane team and Docker for making a smart move. In Socketplane I see a group of individuals who have both the desire and ability to engage with the entire open source community to bring the best possible networking to Docker.
If you read the Docker press release then I hope you were not too surprised to see a quote from me, on behalf of Weaveworks, in support of this move. After all, Socketplane is a competitor – so why should this be good for us?
I said:
“Our customers, including those in production, ask for APIs to extend Docker and Weave … We have all been working to address this, starting with enabling networking extensions. Delivering a network API is now a resourced priority for Docker. Networking is just the beginning – Weaveworks looks forward to uniting with Docker and the ecosystem, to define, ship and support these APIs.”
The reason I said this boils down to one concern alone: making the customer happy.
What customers ask for
Customers and vendors must unite around a common goal here.
Our customers use Docker. What they tell us is that they also want to choose the supporting technologies that work best for them. They do not want to use an “all or nothing” monolith. Docker will fail catastrophically, in my view, if it becomes a big monolithic thing. Such a failure would hurt all of us. Customers do want to select implementations for services, and plug them into Docker. For example: networking, service discovery, .., e.g. as provided by Weave at production sites like Cloud66 and Tutum. And finally they want to wire all this new technology into their existing operational tooling eg. for monitoring.
The APIs are not there yet to support this and they need to be. It’s that simple. We have all got to make this work.
We want a platform but it has to be open and pluggable
Docker want to be a ‘platform’ on which customers and vendors can build and sell applications. The idea is that it is ‘composable’ ie. extended via plug-ins. Success would mean Docker is a platform but not a monolith. Instead the platform is composed of the Docker core plus a user-chosen set of ‘backend’ extensions. Docker may offer its own extensions and recommend or distribute a common set as a single package, but users may swap these out for third party extensions. The more extensions can be added, the more successful the platform.
Batteries included and removable
All this gets you the ‘batteries included but removable‘ platform that you may have heard of from the Docker team. As a minimum, this requires plugin/extension APIs so that Docker supports the swapping out of default networking, storage, clustering, etc. We shall be doing our best to work with Docker to make these plugin/extension APIs happen for you. Providing this for distributed systems is technically challenging and we welcome all help.
A high stakes game has begun
But getting the tech right is not enough. We also need two things:
- End users must be happy that this promise is met for real
- The ecosystem must enthusiastically get behind this
The bottom line:
How Docker implement and support networking is a bellwether case for their new open and composable platform. From here, Docker can win big by bringing the ecosystem with them, or they can lose big by locking customers in, and partners out. The market will judge Docker harshly if they fail. At Weaveworks we want to see the ‘win win’ outcome and will work to make that happen, because we think this puts customers first.
What happens next?
In my view Docker will now do two things:
- Docker will implement just enough networking, so that multi machine Docker works out of the box without 3rd party dependencies. They need this in order to support an “app store” business model, based around the Docker Hub, in which customers create, share and sell applications that are containerised.
- Docker will implement the open platform. They will create extension APIs to allow other networking implementations, such as Weave, to replace and/or extend Docker’s built-in solution. If they do not do this, then they will lose customers using incumbent infrastructure, e.g. VMware, IBM, Amazon, Google, and all the big independent network providers. The Docker app store / hub model must work for those cases.
As I implied above, the stakeholders in this include not just Docker but an ecosystem of (a) companies and teams that develop and/or sell applications; and (b) the incumbent vendors and start-ups that are betting on containers. These stakeholders have to date chosen to back Docker. Provided the Docker platform is open and pluggable, via a set of APIs, there is no reason for this to change.
Success is within reach
Be assured that success is both possible and really hard to get right.
An existing success story with analogous goals is Spring, which is extremely open and pluggable, while preserving consistent behaviours and offering default implementations. Spring has enjoyed more than ten years of success and continues to surprise sceptics with its ability to innovate with high productivity technology like Spring Boot and Spring Cloud. Spring has become an open platform with Boot at its core, so that new products like JHipster can be offered on Spring.
Weaveworks: our goals and our commitment
In the success scenario, Docker is an open and pluggable platform. And Weave is the very best way to deliver portable networking, service discovery and more things we are working on.
We want Weave to be a poster child for the above platform model. This means, in a nutshell, that when anyone challenges Docker to prove the platform works as promised, then Docker can say “the network extensions (plugins/etc) prove it”, and point to our respective implementations of the functionality.
Our commitments
With all this in mind, Weaveworks are making three commitments:
- To our customers: we will do our very best to make sure you have the best experience if you use Docker and Weave, to solve the problems you are telling us about
- To the Docker team now including Socketplane – we commit in good faith to help create the extension APIs so that Weave and any competing solution are pluggable into Docker.
- To the network provider ecosystem – the plugin model will most likely not work for you, in the event that it doesn’t work for us. We’ll help you to make it work – just tell us what to do.
— alexis
