Docker extensions: the new Docker plugins model

Be mindful of incentives and you can see into the future.

Docker wants to grow (a direction that's out of their hands, as they have a board to answer to). They must do this while playing the delicate balancing act of tightly controlling the project's direction towards their desired list, while at the same time maintaining the goodwill of its community. Part of this is defensive enterprisey blog posts, part of it is singing their praises at their conferences, and part of it is reigning in fractures in their platform back under their own umbrella with a plugin model. I'm not even judging Docker for doing these things; as a funded company they almost have to do these things.

CoreOS wants to ride the same wave, but they know that Docker is encroaching on their turf and will increasingly do so (see above). That's why they're deliberately breaking away with their own format. Core hopes that they can lock away enough of an audience behind their platform before Docker can do the same. They basically had to do this to survive, because Core, being composed of modular components, can't make money when everyone takes their moudlar components and simply runs them under the umbrella of Docker's growing platforms.

And this whole API wrapping thing? It's a power play. Whoever controls the UI holds a captive audience -- literally -- whether that's Docker, Core, or someone else. This is basically war over your servers, though I'm sure nobody involved will commit the PR suicide of admitting it. You are encouraged to engage in healthy skepticism and wonder if this comment itself is written by one of the players.

I have no idea who (if anyone) is in the right here, but I encourage everyone reliant on these platforms to see what's going on beneath the waves. Be mindful of the incentives these companies have, and make your technology choices accordingly.

Luke here, the author of this post. I just wanted to say that Solomon did a great job pulling this meeting together, and that this meeting is an example of a pattern that Docker is using to get community feedback in gradually increasing circles (finally resulting in a proposal on GitHub). IMO, it's a good balance between completely open design and sane forum for discussion!

The model sounds like it might be inspired by git. If it truly is, that would be wonderful. (Example git extension: http://blogs.atlassian.com/2013/04/extending-git/ )

The idea of supplying a convenient set of low-level primitives and then letting you compose them, in any language, and become a first-class citizen (at least in cli exposure) is wonderful.

I could see a world where docker plugins simply work by "docker XYZ" doing a "docker run XYZ" and bind-mounting the docker.sock in as well as providing a few additional convenience sockets / functions / potentially container links.

Making docker plugins also docker containers sounds really appealing to me and if anyone has more information on the actual details being considered I'd love to hear.

I wonder why CoreOS weren't in that meeting. They provide a ton of stuff that could be seen as a docker plugin (flannel being the most obvious imo)

Ah ffs, again another tool another system reinventing/adding-support for the whole application stack from networking to "business logic".

Docker is starting too smell like Java Enterprise Edition, but none-Java, and comes from Linux.

It was supposed to contain an application, now there is special networking needs to support an "application" that is made to run "in" docker, and special software /orchestration to faciliate what is a middle-ware business-domain problem.

Are we going to see books soon with titles such as "Programming your E2E business app on the platform of Docker in 24hours". "Inside your social media networking platform up and running in and with Docker."