Docker May Be A Great Developer Tech, But It Doesn’t Cure Ebola


Pity the child star. Like a Macaulay Culkin peaking too early, Docker, the hotter-than-hot Linux “container” technology, is already coming under withering criticism for not living up to its hype as the reincarnation of Gandhi … or the cure for Ebola.

Which is obviously really, really stupid.

See also: Docker Promises A Standard Way To Package Apps To Run Virtually Anywhere

Let’s be clear: there are lots of reasons to hype Docker. In a world of increasingly distributed applications, Docker’s Linux container technology is rightly celebrated for its ability to streamline and accelerate application development. But some advocates may be going too far in their adulation of Docker, making Docker hate feel like a public service.

A Happy Life With Docker

The cloud has made application development much easier in some ways, as developers no longer need to wait on the IT department to spin up servers for them. But it has also complicated things. Docker’s beauty lies in bringing simplicity to modern application development, as detailed by Jodi Mardesich for ReadWrite:

Docker is creating a massive buzz because it simplifies life for developers. Instead of cobbling together tools and writing apps for specific databases and other software components and operating systems, with Docker, developers can “package” an application in standard containers that can be transferred to virtually any server anywhere, whether it’s a virtual server on the developer’s laptop, a physical server in a company’s data center, or a virtual machine on Amazon’s Elastic Cloud.

This is a very big deal. So much so, in fact, that it has led people like Web programmer Barry Jones to gush about its potential:

[Docker] is going to be the most disruptive server technology that we’ve seen in the last few years. It fills a much needed hole that’s currently managed by very expensive solutions and it’s being actively funded by some of the biggest players in the market…. Docker is actively working to replace the need for hypervisors, virtual machines (VMs) and configuration management tools like Puppet / Chef /CFEngine in MOST cases.

In other words, abandon hope, all ye that enter here to compete with the Docker juggernaut. 

Not surprisingly, such thinking drives technology pragmatists crazy. 

Piercing The Reality Distortion Field

Some, like the authors of the Neutron Drive blog, complain that some “use these powerful tools [like Docker] to just cover up our crappy code.” Others, like Satory Global architect Neil Mackenzie, suggest that it’s not at all clear that Docker maps well to business realities, holding that it’s “not obvious that Docker fits well with the economic model of the public cloud where isolated VMs allows high-density utilization.”

Still others, like 451 Research’s Michael Coté, take a more sardonic tone:

Followed by CSC’s Simon Wardley gleefully heckling that “Docker turned my old ZX81 into a teleportation device and perpetual energy machine.” 

None of these apparent critics is really being critical of Docker itself, though. They’re swatting at the hubris around Docker. This is one of the hardest tasks of any promising technology: reining in advocates, rather than answering critics. The haters will always be there and, if anything, simply serve as a leading indicator of success

But some hate is an unnecessary byproduct of over-the-top adulation. The trick is to help advocates do so in a responsible fashion.

Finding Balance

Consider: it’s possible—even likely—that Docker will threaten virtual machine technology in the long run. After all, as Dell’s Joseph Jacks suggests, “Docker promises to replace heavy VMs w[ith] Linux containers” as its superior isolation granularity means it can deliver “10X+ better consolidation & utilization” of system resources. 

That’s big.

But in the short- to medium-term the two complement each other, Gartner analyst Kyle Hilgendorf notes:

[T]here is room for containers and VMs to live together for the next several years. I see value in two layers of encapsulation, one at the OS (VM) and one at the app (container) and we cannot ignore the enterprise readiness of VM security and VM management tools. Container management and security still needs improvement so why not combine the two worlds?

The best course for the Docker team is to embrace its market-changing characteristics without over-promising its current capabilities and uses. And, to the extent possible, to coach its biggest advocates on present-day limits even as they laud future-day possibilities.

So long as Docker engineers remain confident but humble, acolytes and critics alike will take a more measured tone and allow the project to grow into its potential to disrupt application development.

Lead image by wirralwater

Facebook Comments