Home » Why Broad Container and Docker Container Deployment Not Yet Begun

Why Broad Container and Docker Container Deployment Not Yet Begun

Simon Hørup Eskildsen’s recent blog titled “Why Docker is Not Succeeding Widely in Production” gives a good overview of the state of Docker adoption. With his experience with production Docker implementations at Spotify, he uses this blog to explain the challenges Docker needs to overcome before it becomes widely adopted.

Simon's blog shines light on the missing pieces: what's needed, how soon and why.   His blog is a Phase 1 product roadmap, which, along with release estimates, can help guide decision-making of potential Docker adopters. He points out the dilemma of waiting for new Docker releases or “doing it yourself.”

Simon raises a discussion that needs to happen–the who, what, where and when of adoption. When will there be critical mass of usage mostly designed around Docker? He clearly was expecting Docker in production to be much further along than what has occurred. By now he expected Docker to disrupt the use of traditional tools and to see many new “Docker-ized” production environments.

The reality of lower than expected adoption should not have been a surprise. Widespread adoption will take time for several reasons that go beyond incomplete functionality. Much of the same functionality has been around for years mainly on Windows servers.   Part of the roll-out of virtualization included virtual machines (VMs) that have similar but different attributes than containers and carry similar value propositions: efficiency, reduced complexity, development and test benefits.

Managers of production systems are slow to bring out new functionality for systems that are working. “If it isn’t broke…” It’s going to be a slow process. This will involve integration with software and service applications. Testing these systems will take time, slowing down Docker implementations.

The expectations of Docker-led disruption of the infrastructure may be misunderstood. The big disruption will not come from the bottom; instead it will come from the application level and work itself down. Docker will make it easier and more cost-effective for IT groups to increase the use of Linux. This will lower application costs (Linux apps are generally less expensive) and increase open source usage. This move will pressure Microsoft and VMware.

Toward the end of his blog, Simon discusses some security shortcomings. The main security threat to Docker is the damage that can be caused if an application can “jump” from one container to another on its own (Blue Pill, HyperJumping). This threat can destroy anything in its path. It’s “game over” if that happens. Yet no one seems to be testing for vulnerabilities like these.