>The problem with this pair of assertions is that they neglect one essential aspect of Docker — one that is arguably its killer feature: its open API.<p>Yes, that Open API is great but it does not seem relevant to CoreOS's criticisms.<p>To me, Bryan Cantril's highlighting of "Open API" as a counterpoint would make sense if CoreOS specifically stated that they will create a "closed proprietary API". I didn't think they stated that as an architecture goal. CoreOS wants to create a non-monolithic container system -- and presumably, their alternative will also be an "Open API".<p>Docker's "Open API" for flexibility doesn't allow you to "undo" how Docker internals would run as a pid on Linux. I'm genuinely confused as to why this Open API was brought up. My current interpretation is that it is almost a non-sequitur.
If anything, the cyclical hype/backlash Docker is getting proves that it is popular and that it works for some people. Consequently, the exposure it gets displeases the people for whom it doesn't work or whose philosophies differ. This feels like Politics 101 if you ask me (I know you didn't :) ), and I'm still surprised by how vehement some people get about this, and about software philosophies in general (particularly considering the average shelf-life of most software).<p>All of that aside, I really like Docker, for the API but also partly because of what the CoreOS people complain about, i.e. a relatively monolithic system.<p>I'm a big fan of modular systems myself and I completely get where CoreOS are coming from with Rocket. But sometimes, I just want to be able to use the tool. I don't want to screw around for hours/days/... to put all the pieces together.<p>The network overlay situation is a perfect example. I know there are different solutions out there, in fact I've been trying some of them out at home. But the truth is, I don't want to have/have time to deal with that stuff and I'd much rather get on with my original ideas.<p>Unfortunately in some situations, as beautiful as the theory and principles are, people justifiably simply want things to work out of the box. I find the criticisms on String Theory are a good example of that, whereby the theory is gorgeous, but in practice does not necessarily have the value it intends to. I digress.<p>I love the idea of a super-modular car I can put together myself, change pieces as and when I wish and so on, but most of the time, I just need to get to my destination.
Not sure why, but the tone of this post seems very antagonistic-- as I'm not involved in either community, I'm not sure why but it seems a bit off-putting to an outsider.<p>Is there some open source community beef I missed? Is forking/developing your own container product that evil? I somehow missed where Rocket equates directly to war on docker instead of pushing containers further into the mainstream by adding some differentiation to the space.
I think Joyent's right here. Docker's open and progressively enhanced API is a godsend. Somewhere around 0.7x they basically enabled the entire existence of my business, just by virtue of having a good API.<p>I frankly don't even care about the rest of the orchestration vs bloat stuff - I want a good API and good performance. The rest is secondary.
In my opinion, Docker's killer feature is that installing and testing out Docker is dead-easy - the barrier is very low. People will make a lot of mistakes trying it out, not understanding it completely before they dive in. Hell - looking at most images pushed on the public docker repo makes me cringe and wonder if a lot of the people who get to that point actually understand what the strength of containers like Docker presents them is. But taking the first steps - even if they are wrong - is easy, it's the the first foot in the door.<p>But once you get familiar with Docker - yes the API is a killer feature.<p>Rocket on the other hand doesn't seems to be something someone might try out when he has 10 minutes spare time. Reading the specs and doc, makes me hesitant of trying it, creating an 'image' seems like a ton of work just to try it out. Yes there are some good ideas there, but it would be sad if there weren't.
As someone excited about Docker and mildly annoyed by the idea that there would be _two_ "standard" container implementations, this is reassuring to me.<p>I hope shykes & co see the light and break the "new" aspirations out from the core Docker container; having one binary is aesthetically pleasing but understandably bothersome to anyone who likes modularity (most devs & unix folks, afaict).
Am I the only person feeling disappointment at the statements and attitude towards this from Docker and Joyent. I guess it's natural when you get your first piece of criticism, in the way of "the healthy open source process".