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.
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.