Docker has been taking the software developer world by storm over the last year. As you can see the Google Trends plot below for the term “Docker,”, interest in either the open source project or in the eponymous company has been very high. Further, last week we learned that Docker, the company behind the open source project, has raised $40M in new funding. For those like me who are not directly involved in software development, should we care about this trend? The answer is yes you should, particularly if you are involved in planning, strategizing, or otherwise interested in Cloud. The capabilities represented by Docker technology are a great fit with the vision and promise of Cloud, and could have significant impact on its development from here. 

Google Trends plot for “Docker” requested on Sept. 22, 2014.  Let’s assume Dockers, the pants manufactured by Levi Strauss & Co, are not responsible for the large increase in search since 2013. 

Containers and Docker are changing how developers think about building software

First, for those not familiar with Docker, I offer a quick primer. Docker is, according to Docker.com, an “open platform for developers and system administrators to build, ship, and run distributed applications.” Now, as a non-developer, and admittedly I have not been a system administrator in eight years, what does this mean? As many things go in computing, what we think is new is actually built on something old, and in this case Docker comes from the ability of the Linux operating systems to “containerize” software programs. Linux containers (often abbreviated to LXC) allow you to run multiple programs in parallel on top of a single Linux operating system. Rather than thinking of this as virtual machines where each VM rides on top of a hypervisor and each with its own guest operating system, LXC gives each container its own bit of physical server resources (like CPU, memory, and I/O) directly from the host. Further, all the containers can share the same host Linux operating system, thereby removing the need for a guest OS as we find in the VM model. The interesting part is any special bit of code not normally part of the base operating system, often call a dependency, can be packaged up inside the container along with the code. That’s a lot to think about, so below is a graphic borrowed from Docker.com to aid in understanding the differences between VM’s and containers.

 

Graphic showing the difference between traditional virtualization as the industry has come to understand it, and the Docker container model taken from www.docker.com/whatisdocker.

 

There are a few great things about this model if you happen to be a developer. First of all, as a developer, it seems to me you really just want to get to the creative part of your job, which is to write code that solves interesting problems. In the simplest of terms, you want to write code, test it, and then put it into use in “production.” Docker is great at this, because you can write and test code inside containers running on your laptop, then publish those same containers into production. The application has a very high likelihood to run in production just as well as it did on your laptop since nothing has changed as far as the program cares about (i.e. the underlying operating system, the code, and the dependencies are all the same). 

Now, life is not that simple and applications are rarely written as one large program that can be completely defined within a single container. This is where Docker really helps developers get to the fun part of their job. Since the value of Docker is the ability to maintain a well-defined, and reproducible, unit of code that can be transported, it supports the notion of micro-services. Micro-services are apps that perform a well-defined function, such as a database service or a web server, which individually handle a portion of a larger programmatic goal. Micro-services expose themselves to the outside world through simple API’s. So as a developer, it would be great if I don’t need to reinvent and hence recode these services each time I create a new program. I can just grab these micro-services as containers, and link them together with my own containerized micro-service to build a larger application. Developers have been using tools such as GitHub as a place to store and share reusable code. Now, Docker Hub performs this same function for entire containers in the Docker ecosystem. Today, Docker Hub Registry contains 30,000+ such reusable Docker containers (see https://registry.hub.docker.com/).

The implication for Cloud

You can see why Docker makes developers happy, and hence change the way they think about building software.  I have hinted on how this technology can change how apps are built and how they get deployed. Rather than think of cloud as a place to run VM’s, we can now think of the cloud as a place to run micro-services. These micro-services, running in Docker containers, can be moved from cloud to cloud and scale up and down without worrying about rebuilding and patching guest operating systems. Hence, the future will be micro-services loosely coupled that need integration and orchestration. Some newly formed companies are already addressing this space, and it will be interesting to see how this flushes out. As Don Ferguson noted in his blog, this trend may be seen as the merging of PaaS and IaaS together as a single layer. We will also need tools for testing and deployment of multiple container applications. Cloud hosters will potentially have more latitude to move workloads around because code will be running in smaller more manageable pieces, rather than big monolithic VM’s. In theory, the underlying cloud hardware could be changed more frequently as well. This kind of reality is sounding more cloud like than our VM paradigm of today.