In the late 90s, I had a short-sighted reaction to Microsoft bundling Internet Explorer with the Windows OS. While the technology world grappled with the legalities, ethics and impact to competition, I was just happy to have a browser that was faster and easier to use.
I’m writing this at DockerCon16, where yesterday’s keynote reminded me of the IE/Windows play. The Docker team announced that container orchestration is now bundled into the Docker 1.12 container runtime. Important updates include:
- Any instance of the Docker runtime can now easily join a Swarm
- Allow creation, scaling and network load-balancing across containers
- A new application format (Distributed Application Bundle) that describes the “full application stack” across images, networks and routing
In a nutshell, it now takes just three or four commands at the Docker command line to orchestrate application services:
# initialize docker swarm init # create an overlay network docker network create -d overlay mynet # create a web-frontend docker service create –name frontend –replicas 5 -p 80:80/tcp –network mynet mywebapp # create a backend docker service create –name redis –network mynet redis:latest # scale a service to 100 containers docker service scale frontend=100
Why is this announcement so interesting?
First, the obvious: in many ways, this is a good thing for the container community and should further accelerate software development productivity using containers. It’s now remarkably easy and elegant not only to run individual containers, but also define portable application services and manage the lifecycle of those application services using containers.
In addition, Docker says that their “batteries included but replaceable” philosophy continues, so developers are free to use other container orchestration frameworks.
However, this announcement raises questions about Docker’s philosophy of cooperation with the Docker community. For those in the know, it appears that the orchestration capabilities announced were inspired by Kubernetes, the open source orchestration framework developed by Google and The Cloud Native Container Foundation.
By embedding the best aspects of Kubernetes directly into the Docker runtime, it appears that Docker is enabling the vast installed base of Docker users to use a bundled solution and thus easily embrace Docker’s own container orchestration technologies.
Talking with Docker users at the conference, I was asked by multiple attendees why they should consider any alternatives now that container orchestration is effectively built in to the Docker runtime. It is a fair question, and users should definitely consider a built-in solution if it fits their use case and needs. However, as Kelsey Hightower (a Google employee and well-regarded engineer in the community) pointed out on Twitter, this isn’t a zero-sum game; multiple container orchestration technologies can co-exist.
In the long run, two things are true: 1) competition is good for customers and provides them with choices and 2) the technologies that do the best job of anticipating and meeting customers’ needs will lead the pack. Nonetheless, one has to wonder if Docker isn’t exercising an unfair advantage given its access to the massive installed base of its container runtime. And will Docker continue to cherry pick from the community to bundle best-of-class capabilities into the container runtime? So – like my conflicted feelings about IE and Windows – I am happy for Docker users who get a solution that is no doubt well packaged and elegantly executed – both historical Docker strengths. But as to whether this is good for the community over time, it remains to be seen.
What this Docker move brings into ultra-sharp focus is the need for those in the Docker ecosystem to continually innovate and execute to provide differentiated value for customers. Some may even consider how to embrace more of the Docker technology stack (Docker orchestration, not just Docker runtime) while extending their offerings in new ways.
Back in the late 90s, I was pleased as punch to have a faster, easier browser in IE4. However, by 2003 I was dissatisfied with the ever degrading IE experience, and switched to Firefox and then to Chrome (with a brief tryst with Safari).
Docker has pulled one from the Internet Explorer playbook. The jury’s out on how it will ultimately shake out, but it will be fascinating to watch how they and the Docker community execute from here on.