Recently at the Google Cloud Platform Live, Amazon re:Invent, VMWare VWorld and at the OpenStack conference, everyone was talking about Docker containers. Even Microsoft has recently announced that it will provide support in the Windows operating system for Docker containers. In this blog I will briefly talk about what is Docker, why is there so much excitement about it, and my take on how this development offers more choices to the end customers.

Simply put, Docker is an application level container mechanism. The main difference between a Docker container and a Virtual Machine container is that a Docker container is a lighter weight container that does not package the guest OS inside it, whereas, a Virtual Machine container is a heavier container that packages a guest OS. Thus, multiple Docker containers share the same underlying OS, whereas, each VM container has its own guest OS. The Docker container paradigm allows one to have stateless application level compute containers, and it also allows for the storing of the persistent state of an application in a separate Docker storage container that can be shared across multiple Docker application containers.

In addition to a Docker container, one also needs a container orchestrator to move a Docker container between the nodes in a cluster, and eventually, across clouds. Google and Amazon are both supporting competing Docker container orchestrator initiatives. Google is putting its weight behind the Kubernetes open source initiative, and Amazon has recently announced the EC2 Container Service. Cisco and VMWare are also planning to provide support for Docker containers in their multi-cloud initiatives such as InterCloud and vCloud Air.

The reason why there is so much excitement about Docker containers is because of the light-weight nature of these containers one can pack more Docker containers on to a physical server than VM containers. Thus, this leads to higher resource utilization. Docker containers also allow for the seamless movement of applications across physical machines regardless of the hypervisors running on those physical machines. Eventually, the goal of the Docker paradigm is to allow developers to specify the infra-structure level policies with respect to performance, disaster recovery, security etc. at the Docker container level, and for the orchestrator to interpret these policies and take the necessary actions. This key development gives more control to the application developer with respect to the underlying infra-structure.

In addition to the above mentioned benefits, I am particularly excited about the following additional benefit which I think has not been talked about much in the community. Currently, it is not easy for a customer to easily move the entire state of their application across the different IaaS vendors because each of the IaaS vendors uses a different hypervisor or container mechanism. Thus, in future, if applications are architected into a combination of stateless application compute Docker containers, and stateful Docker storage containers, then this gives an application the freedom to move the stateless compute containers across the different IaaS providers, while keeping the stateful storage containers in a common location such as an Equinix datacenter that can be efficiently accessed from all of the IaaS vendors’ infra-structure.

Furthermore, this also allows various storage and database vendors (both SQL and NoSQL) to host their storage/database as a service in the Equinix datacenter. The net winner out of this entire paradigm shift will be the customers because they will be able to build their distributed multi-cloud applications by leveraging the services across multiple IaaS vendors while maintaining the stateful components of their applications in a common location like the Equinix datacenter. I am a strong believer in giving more choices to the customers, and whenever, there is a paradigm like the Docker containers, that allows customers to separately shop for compute and storage services, I am all in favor of it.