> From a purely technical perspective it's not very interesting or irreplaceable, the way that OpenVZ or lxc are.
Obviously I am biased since I work on Docker. But I completely disagree. I believe Docker has the potential to be quite important and quite irreplaceable (in other words: useful!), although in a very different way than openvz and lxc. If I didn't believe that, I wouldn't be spending so much energy working on it. And if you don't understand why developing Docker is a lot of work - actual engineering work, not marketing, although that is important too - well one of us is overestimating his understanding of the topic :)
My guess is the overestimation is mostly on my side, but a bit on your side :-)
I created a simple deployment system using auto-generated and versioned OpenVZ templates. Achieving something pretty similar to what Docker buys you. It's pretty trivial to do that much, which I think can fairly be said to be the core of what Docker is.
I realize that Docker is trying to do a lot more than that, and those things probably will end up being very useful and valuable. I'm sure there's a lot of hard technical work involved in making them happen.
And there's a reason I deleted my original comment. I truly don't have any desire to call your baby ugly. I'm sure you guys are putting in a lot of effort and I truly am excited that it exists. Infrastructure software written in Go automatically earns my vote.
Anyway, good luck. Don't let the^Wus bastards get you down!
Thanks - it's good to see it's still possible to disagree constructively on HN :)
Yes, I think it's fair to say that a skilled sysadmin can assemble a system quite similar to the core of docker. In fact many, many sysadmins have. The result is an ocean of DIY container management tools, each incompatible with the other, and each not quite generic or polished enough to be made usable by others because, well, sysadmins have real work to do :)
So the question really is: is it valuable to federate efforts so that instead of 1000 incompatible and unpolished tools, we get a small number of tools which are more polished and more interoperable? I believe the answer is yes, because it allows the use of containers not just as a site-specific deployment tool, but as a mechanism for code distribution and re-use. We can make containers as useful as libraries! That is not possible unless we agree on some sort of standard "call convention".
Now, you may agree with this but answer "but these tools already exists: look at lxc, openvz and libvirt", then I respectfully disagree. If those tools were sufficient, sysadmins and developers would just use them directly, instead of each writing elaborate abstractions over them. These tools were not designed to use containers as units of software distribution and re-use. They were designed to use containers as lightweight servers. Basically like a VM but faster. Those are useful tools - but they serve a different purpose than Docker.
I think this is actually one of the best formulas for successful products. The productization of systems that lots of companies are already forced to individually build themselves.
Probably what colors my perception of Docker's triviality stems from the initial version that I checked out. Having just checked out the latest version now I can see a ton of work has been done.
The first version of Docker probably isn't much more than what an ambitious internal project might look like. The latest version is exactly what you'd get if a company put real effort into it.
And I actually completely agree about creating high level interfaces. I'm not someone who argued that Dropbox shouldn't exist because I personally know how to use rsync quite well.
Obviously I am biased since I work on Docker. But I completely disagree. I believe Docker has the potential to be quite important and quite irreplaceable (in other words: useful!), although in a very different way than openvz and lxc. If I didn't believe that, I wouldn't be spending so much energy working on it. And if you don't understand why developing Docker is a lot of work - actual engineering work, not marketing, although that is important too - well one of us is overestimating his understanding of the topic :)