The (Real) Problem With Docker
The inevitable Docker backlash has begun. Accusations range from incompleteness to a lack of security. And, for the most part, the accusations are true.
However, they’re completely misguided, based on what appear to be unrealistic expectations for an otherwise exciting technology. The real problem with Docker is that Docker’s the source of these expectations.
Take a look at the Docker web site:
This is the tag line, as of this writing:
An open platform for distributed applications for developers and sysadmins
Further down the page, they say:
Avoid the usual headaches of conflicts, dependencies and inconsistent environments.
When you make claims like this, you can’t really complain too much when people get upset that you haven’t solved all their problems.
What Went Wrong
Container technology is a big advance, just as virtualization was a big advance. Docker was among the pioneers in making this technology more accessible. This was a Good Thing.
But then Docker decided to raise a lot of money. This had the unsurprising effect of turning Docker into a company that was very focused on revenue growth. And also, consequently, much less concerned about their original mission: making container technology easier to use.
Consider Docker Swarm. Swarm allows you to deploy containers to a cluster of machines, instead of to just a single machine. Which is very nice. In fact, we’ve been working on a similar technology here at Panda Strike.
But then we read this:
Swarm comes with a built-in scheduler, but you can easily plugin the Mesos backend for large-scale production deployments
Now, if there’s anything we’ve learned about Mesos, it’s that you shouldn’t use “Mesos” and “easily” in the same sentence. So why would Docker promote the use of Mesos for production applications, while simultaneously promising to avoid the usual headaches associated with deploying applications?
The answer is in the menu bar at the top of the page, under the headings of Support and Training. This is how Docker manages the risk to their investors. They want you to believe that, indeed, Docker is the future. But they don’t want you to get the idea in your head that you don’t need help realizing that future. And there are lots of big enterprise IT shops who will fork over large sums of money for that help.
There’s nothing wrong with that strategy. Except that it does the entire industry a disservice by conflating the genuine promise of an emerging technology with the hype surrounding it. Neither Docker, nor containers, will solve all the myriad concerns related to deploying and running real world applications. But containers are still a big advance.
The advance is simply that they allow for more efficient virtualization.
And, yes, that’s basically it in a nutshell.
The real solutions around containers will be focused on making them easier to use, just like Docker did originally, and just like Heroku did for cloud-based virtualization back in 2008. That’s why we’re continuing to invest in projects like Huxley. And that’s why you shouldn’t disregard containers as being more trouble than they’re worth.
Just remember the immortal words of Flavor Flav: don’t believe the hype. In fact, don’t believe the backlash, either. Exaggerated claims, overenthusiastic early adopters, and subsequent criticism — overly harsh subsequent criticism, in most cases — are all normal parts of the lifecycle of an emerging technology. But if you want to use this kind of stuff in serious production contexts, you have to take both the hype and the backlash with a grain of salt.