3 ms·
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
by fundies 12y ago
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.
- kelseyhightower 12y agoDisclosure: CoreOS employee. The application container specification (ACI) and the initial implementation, Rocket, are here to provide balance to the container ecosystem. If you review the draft spec (http://bit.ly/1s4Om8p http://bit.ly/1s4Om8p) you can see it's clear that the proposed specification is designed to remove the need for a "vendor" when it comes to building, distributing, and running containers. As an example everything in the spec can be accomplished using a handful of Linux command line utilities such as gpg, tar, and systemd-nspawn -- you could use lxc or libcontainer as well. When it comes to distributing container images the ACI spec only requires hosting ACI images (tarballs) behind a HTTP webserver and leverages DNS instead of custom registry APIs. The ACI spec skips the app store model in favor of simplicity -- think RPM and YUM. docker vs rocket? Don't really care about that right now. Nothing wrong with Docker providing value, and yes, docker provides tons of value. Rocket is just our (CoreOS) attempt at providing value in a slightly different way. IMO the only people that should "own" the container spec are the people using it, and right now I believe that is the main driver behind our (CoreOS) intentions for proposing the ACI specification. I know I'm biased by association, but trust me, I want using containers to be a simple thing. In reality using containers should be about as exciting as: $ yum install app; service start app
- thebyrd 12y ago+1
- jzxcv 12y ago(disclosure: another CoreOS employee) > When it comes to distributing container images the ACI spec only requires hosting ACI images (tarballs) behind a HTTP webserver Just to clarify a little: the spec [1] actually only stipulates that the _metadata_ for image discovery is provided over HTTPS. The actual ACI images (i.e. tarballs) can be distributed using any desired mechanism. For example the meta discovery service can provide HDFS and BitTorrent addresses, and then a client can choose how to retrieve the payload. This is one of the parts of the spec I'm personally most excited about, so would welcome feedback and/or implementations! [1] https://github.com/coreos/rocket/blob/master/app-container/SPEC.md#meta-discovery https://github.com/coreos/rocket/blob/master/app-container/S...