I deleted my comment before you replied, because while I tried not to made it rude, I decided there's no reason to add another negative voice to this thread.
The fact is that Docker is very useful, but it really is simplistic from a technical perspective. It's a front-end that leverages the very impressive and very hard work done to create Linux, LXC, Aufs, etc. Those guys deserve 98% of the credit that Docker is getting, which I admit does irritate me to some degree.
Yes, Docker is a high level abstraction that could use OpenVZ or something else, but if it used OpenVZ I'd just say that the OpenVZ guys deserve most of the credit -- having done most of the hard work.
Docker is the kind of thing that companies create internally all the time, the way you did at dotCloud. It's very neat that you open sourced it, and that it has brought attention to another way of doing application deployment, but that doesn't make it a revolutionary technology.
The revolution isn't in the technology. You're right; Docker is just a standardization of the use of these other components, for people to rally around. But the rallying-around is the revolutionary part. If everyone builds their own Docker, we can't interoperate at a "container" level. If everyone settles on one container format, we can.
In my opinion, Docker-the-implementation is only interesting insofar as it increases the network-effect of Docker-the-container-format. :)
Likewise, it irritates me when people put something down for popularizing an idea without too much technology. This "who needs marketing? all we need is code!" code is exactly why desktop Linux never took off. Popularization and marketing by themselves are very important, I'd wager at least as important as the code. What good does your code do if few people know about it or how to use it? The Docker guys are doing LXC, Linux, Aufs etc a huge favor.
I think you could argue that Docker (and similar projects sure to come) are merely the inevitable result of creating technology that's extremely useful and publicly available. No one marketed Xen, OpenVZ, or KVM. They run on millions of servers today. Certainly no one confuses those technologies with the many wrappers for them.
And I'm not trying to hate on Docker either. I think it's cool and I'm sure the guys that work on it are nice. But I must agree with the root comment (though not his tone). From a purely technical perspective it's not very interesting or irreplaceable, the way that OpenVZ or lxc are.
Those are not very good examples. Xen was very heavily and skillfully marketed by its corporate sponsor, XenSource, and after that by various companies with a financial stake in the project.
OpenVZ was the flagship technology of Virtuozzo, and is now at the heart of Parallel's commercial offering.
KVM was the heart of Qumranet's offering, which was then acquired by Red Hat.
So all three of these examples are factually wrong: all three technologies were heavily marketed, both externally (getting customers to use it) and internally (getting other businesses to support it, contribute to it, and lobbying to get it merged upstream). Arguably none of these projects would be so widely adopted without the marketing efforts of their corporate sponsors.
Better examples might be vserver or qemu, who are not directly linked to corporate sponsors (that I know of).
> 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.
"This "who needs marketing? all we need is code!" code is exactly why desktop Linux never took off."
No - it absolutely isn't. I cannot emphasise that more. It isn't at all why "desktop linux" didn't "take off".
Let's not open up the whole desktop linux thing, but a desktop linux that had "taken off" is almost certainly not a desktop linux that I'd want to be using. As it is desktop linux works seriously well for very many people.
The fact is that Docker is very useful, but it really is simplistic from a technical perspective. It's a front-end that leverages the very impressive and very hard work done to create Linux, LXC, Aufs, etc. Those guys deserve 98% of the credit that Docker is getting, which I admit does irritate me to some degree.
Yes, Docker is a high level abstraction that could use OpenVZ or something else, but if it used OpenVZ I'd just say that the OpenVZ guys deserve most of the credit -- having done most of the hard work.
Docker is the kind of thing that companies create internally all the time, the way you did at dotCloud. It's very neat that you open sourced it, and that it has brought attention to another way of doing application deployment, but that doesn't make it a revolutionary technology.