3 Drastic Reasons Containers are Causing a Seismic Shift in Technology

Without your knowledge, the solid foundation that the technology you use everyday is undergoing a dramatic shift. A technology called containers is rapidly growing and it may change how IT departments are organized and how the websites and applications you use everyday are deployed.

If you’re in IT you've heard of VM Ware and server virtualization. Many IT departments are pushing for the ultimate goal of having their server infrastructure 100% virtualized. In other words, IT departments want to fully utilize the hardware that they've paid for by running "virtual" servers on their physical hardware. VM Ware and it's main competitor, Miscrosoft's Hyper-V, created the Intel server virtualization market starting in 2001.

If you are a programmer or techie, chances are you’ve at least heard of another type of virtualization called "containers". It would be hard not to, with all the attention it’s getting these days — from developers and system admins alike. Even the large cloud providers like Amazon, Microsoft, and Google are building services to support it.

Server virtualization has changed how IT is run and the emergence of containers has the same potential to shift the IT landscape. Containers help IT departments achieve the following three goals:

Be Innovative

React Faster to Changing Business Needs

Save Money

In order to understand what containers are and how they work, let's take a moment to review the history that brought us to this point.

Let’s start by understanding what drove the adoption of x86 based server virtualization.

Server virtualization and VM Ware

Before VM Ware started the server virtualization wave, if you wanted to deploy an application, you had to purchase a server. As Moore's Law drove the processing power of CPUs to greater heights, IT departments began to find that they had servers that were under utilized. Corporations started looking to their IT departments to operate more efficiently. This drive for IT efficiency rose to a new level after the ".com Bubble" burst and IT engineers began looking at ways they could better utilize the hardware they had already invested in.

The way that VM Ware solved this problem is by tricking the operating system into thinking that it was running on dedicated hardware. VM Ware created a software layer between the server hardware and the operating system that enabled multiple operating systems to share the same hardware. IT departments could now increase their efficiency by utilizing more of their unused CPUs.

For those that were in the industry at the time you will remember how you searched for "opportunities to virtualize". Initially, moving an application to a virtual server was risky. System Administrators looked for easy applications to move, such as web servers, which were usually load balanced across servers which were running identical configurations and did not have a dependency on high transaction storage. The next migration was looking at servers that had a high transaction load like databases and evaluating whether those servers could be virtualized. The migration continued until today with IT departments looking to refactor legacy applications so that they can be moved to a server running in a virtual environment.

The Virtual Machine Approach

The VM approach helped IT departments save energy and make their datacenters more environmentally friendly. The drive for energy efficiency had already begun with the shrinking of servers from a 8u, to a 4u, to a 1u "pizza box", and then to a blade server architecture. The condensing of the footprint of physical servers helped reduce the datacenter footprint and virtualizing the operating system allowed this consolidation to continue. Using virtualization software also allowed system administrators to deploy servers faster. Traditionally hardware had to be purchased, installed in a rack, then the operating system installed. Taking weeks or months to complete, it could now be done in a matter of hours or days with virtual machine creation, without having to install, or invest in, hardware. This helped make IT departments more responsive to business needs and they could get applications or additional capacity available faster.

The Virtual Machine approach solved the problem of more efficient use of excess hardware capacity. It was solved by looking at the problem from the hardware up the stack to the application. By fooling the operating system with hypervisor software, system administrators were able to run multiple instances of the operating system on the same hardware and therefore run multiple applications on the same hardware.

However, this created an opportunity for improvement that no one anticipated. The minimal install size of Microsoft Windows Server 2012 is 32GB. This means that for each virtual machine, you will need at least 32GB of storage space. Additionally, each virtual machine initiated every service that was run by that operating system, whether you wanted it or not. What system administrators really wanted was to run multiple instances of the application. Software developers also started to encounter the "works on my machine" problem. IT departments may run tens, hundreds, or thousands of VMs and the task of keeping all of those VMs patched and/or updated, became more and more difficult. Software developers looked for a new way to deploy and move applications without needing to recreate the entire server. In 2013, an open source project called Docker was released that used a virtualization technology called Containers. One month after launching an interactive tutorial on how to use Docker, 10,000 developers downloaded it.1

The Containers Approach

The VM approach solved the resource utilization problem from the hardware stack up. The Container approach solves the resource utilization problem from the application stack down. The container approach solves other problems simultaneously and plays into the idea that software is eating the world. Utilizing containers, software developers cannot only be sure that what they write on their laptop will function as intended in production, but they can also build, ship, and run new updates to their applications in minutes, if not seconds. The container approach supports the idea of infrastructure as code allowing the application development team to provision and build infrastructure directly from their software. This has enabled the idea of the serverless datacenter, supported by Amazon with their Lamba function service and Microsoft with their Azure functions service. The serverless datacenter is just a natural evolution of the container approach.

For all intents and purposes, containers appears as a VM. To the applications running in a container they have network connectivity, storage, and access to CPU and RAM, everything they get from running on an OS on bare metal or an OS running in a VM.

The one big difference between containers and VMs is that containers "share" the host system’s kernel with other containers.

Add alt text No alt text provided for this image

Whereas a VM uses software to fool the operating system into thinking that it's running on dedicated hardware, containers fool the applications into thinking that they are running on dedicated operating systems. This allows containers to leverage the part of the operating system which is the same for each server and not cause a duplication of this code for each new instance. Each container gets its own isolated user space to allow multiple containers to run on a single host machine. The operating system level architecture is being shared across containers. The only parts that are created from scratch are the parts of the application that are unique to that application. This is what makes containers so lightweight.

A VM is called a virtual machine, because that's what it is. It's a server that exists only in the virtual world, enabled by the hypervisor software. A container is called a container because it steals from the idea of shipping containers.

Shipping containers were a revolutionary idea and changed the shipping industry forever. Before shipping containers existed, cargo was loaded into the hulls of ships and taken across the ocean. While this system of transportation worked, it was an inefficient use of space. If a ship was transporting bananas, the space above them couldn't be used, because you couldn't stack anything on top of them as well as the amount of time it took the crew to carry and pack the bananas into the hold. With the invention of shipping containers, those bananas could be loaded into a box, which could then quickly and easily be loaded onto a ship and the next shipment of wheat could be loaded into a container and then stacked on top of the first container. Loading times were reduced and the amount that each ship could carry was increased. Eventually the entire shipping pipeline changed so that cargo could quickly, easily, and cost effectively be loaded, moved, and unloaded. It has become so efficient that to this day, shipping by boat is still one of the most cost effective ways to move large cargo.

Software containers use this same idea. The software developer starts with a base image, the operating system of their choice. They then stack on top of that base image other tools, software, or libraries that they will need for their application. Once they've built their full stack, they can now create a new image. This new image contains each of the layers that they added to their base operating system image, and they can push this new fully contained application image (including the operating system) to a repository like Docker Hub. Once the image is in the repository, anyone can then pull the image down and with one simple command, run the image which includes the operating system and all pieces necessary to run an application.

Below is a comparison that was published by Microsoft about running a Node.js application on their server virtualization software Hyper-V and running the same application in a container.

Add alt text No alt text provided for this image

As you can see, running an application in a container will reduce the start time by a factor of anywhere from 5 to 60 and use an order of magnitude less storage space.

Containers are gaining in popularity because of how developers can build and ship images and can integrate this process with their tools like Git. The development community is excited about the possibility of containerization due to its integration into their Continuous Integration/Continuous Deployment pipelines that allow them to deploy software faster, but it also helps move them to running infrastructure as code. IT departments should be excited about this technology as well as they have the opportunity to continue their efficiency gains of the past decade by using containers.

IT departments should be evaluating where containers can be utilized in a similar manner to how they evaluated and deployed VM server virtualization. Opportunities will present themselves where this new approach can be utilized and they can increase their efficiency by deploying certain applications in containers. Over time, much as with VM server virtualization, we may see container virtualization grow to the point where IT departments are striving to get to 100% containerized.

Conclusion

The container approach is being endorsed by the open source community as can be seen by over 35,000 containerized applications available in the Docker repository and 21 million downloads of the Docker software. Software giants Amazon, Google, and Microsoft have all thrown their support behind it, not only by launching services that you can run in their clouds, but Microsoft has enabled support for containers running in their server OS. Google has been very open about their use of containers and have released their container orchestration engine Kubernetes (originally called Seven of Nine, the member of the Borg that was friendly to humans). The level of excitement and the enthusiasm behind the container approach make it look like this is a technology which will make it past the hype cycle and make it into everyday use. IT departments should become familiar with this approach as it also plays into the idea of the software defined datacenter, software defined networking, serverless computing, an API for everything, and the enterprises' drive to foster innovation. The container approach, combined with some of these other concepts has the potential to completely shift what it means to run an IT department. We could be moving from a system of system administrators and architects, to a structure of plumbers and ops developers. The plumbers rip and replace failed hardware and the ops developers manage the infrastructure.

I hope that you've found this article informative and feel free to ask questions where you may want more details or dive into more depth on any aspect of what I discussed above.

In my next article I'll dive into more detail about how the Docker container runtime works. I also plan to write about my experiences playing around with containers in future articles.