Docker, Part 2: Whoa! Spontaneous industry standard! How did they do THAT?
OSS guys acting as one ... it's not natural
Sysadmin Blog Docker is slowly taking over the world. From its humble origins, which we explored on Friday, as an internal project at dotCloud, through to Microsoft's recent announcement that it will support Docker natively in Windows, Docker looks set to become a major component of modern IT infrastructure.
Today, Docker is powered by Libcontainer, rather than the more widespread LXC. The switch has some very real implications for the future of Docker, for its potential adoption and for its interaction with the community.
Libcontainer matters for the same reason that Android matters: control. Consider for a moment that while there are eleventy squillion distributions of Linux out there, almost nobody says "Android Linux." They'll say "Red Hat Linux", "Ubuntu Linux" or "SuSE Linux", but they won't say "Android Linux."
Derivatives of Android – such as Amazon's "Fire" clone – are referred to not as new distributions of "Linux", but as "Android variants". Compare this to Mint: a derivative of Ubuntu which is a derivative of Debian, but all are commonly simply called "Linux".
Under the careful ministrations of Google, Android became its own "thing". Linux distributions tend to have various things in common. Package managers, various common tools and packaged, similar boot initialisation procedures, file layouts, etc … all subject, of course, to fragmentation. Android took the kernel from Linux, some of the basic ideas, and just ran off in a completely different direction altogether.
With libcontainer, Docker are doing the exact same thing. Docker isn't going to play politics with the distros on how and when they implement LXC. Docker isn't holding group hug meetings to make sure everyone is okay with the emotional impact and philosophical concepts behind each and every decision.
LIbcontainer is Docker's own; the company will implement it how they like and if you don't like it you can go jump in a lake. Run whatever OS you want underneath, but it's Docker that will provide you your containerisation.
A bold move
This is exactly the sort of move that usually doesn't go down well in the open-source world. For every "you will do it our way and you will like it" that results in an Android, there are a dozens failures of leadership that result in catastrophes like Ubuntu's Unity or Oracle's slow motion MySQL trainwreck.
Google had billions upon billions of dollars and a decade's worth of goodwill to burn that allowed them to bully the world into making Android the dominant smartphone (and quite possibly embedded) OS. What does Docker have that is earning it such overwhelming hype, and allowing it to get away with a rare form of dictatorship in the open source arena?
The answer is not one thing, but rather a combination thereof. First off, we must start with the fact that dotCloud is the commercial backer of Docker, and this makes all the difference. DotCloud had a stable source of revenue unrelated to Docker itself and had a firm set of commercial partnerships and contacts in place long before Docker ever got born.
These relationships and partnerships took time and skill to forge. The experience and connections gained while doing so helped to bring about strong support from across the open source community. Companies like RedHat, Canonical and Google that traditionally believe Linux should evolve differently – and which take their distributions in radically different directions – were all convinced of the value of supporting libcontainer as a single unified standard, with Docker at the center.
This was accomplished with skill and patience, and by obeying Wheaton's law. Docker is giving as good as it gets, and so valuable is the coalition of contributors that even Parallels – who, if you remember, make Docker's primary competitor, Virtuozzo – are contributing code and working as part of the team.
In essence, dotCloud managed to forge a cross-corporate industry standard out of competing companies without a lengthy IEEE-like bureaucratic nightmare of a process. More importantly, they got out in front of the thing and did it first; imagine where public/private/hybrid cloud computing would be today if we could have convinced the various players involved to agree to a single virtual machine standard!
When you consider how deeply invested these companies were in previous iterations of containerization technology – Google's Let Me Contain That For You (lmctfy) being an immediate precursor to Docker – the feat is all the more impressive.
Of course, we have all seen standards fail. Why does Silicon Valley seem so convinced that Docker won't?
Most large technology companies would like you to believe that the opinion of the end users is irrelevant. Unfortunately for them, you can stand there screaming orders at the herd until you're blue in the face, but they're just as likely to trample you into the ground as move in the direction you want. Docker's principals have actually learned this lesson and they made the thing easier to use than any available alternative.
The big secret sauce is the concept of "images". Think of these like templates for hypervisor-based virtualisation. Click button, spawn image, seconds later you are ready to go. It is that easy.
Docker is also highly scriptable and has a lot of deep connections to the DevOps community. If you use Puppet, chances are you love Docker, and the brigades of PowerShell aficionados are pretty pumped about it as well. Docker's copy-on-write capabilities offer DevOps teams the ability to create and destroy application clusters (think vApps) with the same ease that they would call a function in their code.
Docker even comes with the ability to restrict each instance's resource usage so that "noisy neighbour" resource consumption isn't a problem. Webscale DevOps teams have found a new sort of nirvana.
Real world value
Docker gets easy wins from large enterprises looking to redo their applications. It is a threat here not to VMware or Hyper-v, but to AWS and Azure. Companies that were already willing to recode their apps from scratch for the public cloud will find Docker a hugely compelling alternative.
Containers on commodity hardware offers a new price point that the public cloud can't meet, and has no interest in trying to. Public cloud providers are already locked in a potentially fatal race to the bottom, and they aren't going to go up against Docker using existing technologies.
For the niche of workloads that containers excel at, the only way to beat them is to join them. Expect cloud providers to do exactly that – and in a big way – over the next 12 months. Whether they adopt Docker or try to roll their own is still up in the air. ®
Read part 1, 3 and 4 of this four-part series: