The Containers Magic

If you like to follow the trends on web application development, chances are that you have already heard about Docker and containers. Although this technology has been around for a while now, it is comparably new and many companies have yet to adopt it. I will give a high-level intro about containers technology here. My goal, however, is to talk about the history of virtual machines (VM) and compare this new technology to the old way of doing things to highlight the benefits of using containers.

History: Physical Servers

Back in the day, let’s say early 2000’s when we deployed a new web application, physical servers were required. Companies had large and expensive IT teams dedicated to set up and maintain the farm. Most of the time one application ran on one physical server. For every new application to ship, the IT team was busy procuring new servers and the company had to incur the initial capital expenditure and maintenance costs later.

That was fine, but the question always was, how big does that server have to be? We don’t want to acquire a server that is slow and will become a bottleneck down the road, right? To play it safe, we always went for big and fast servers to be cautious. The result was that we quite often ended up with massively over-sized and expensive servers that were barely 20% utilized yet the company had to spend time and resources to maintain them.

Medieval: Hypervisor Virtualization

When hypervisor was introduced to the commercial IT world, all of this changed. The technology revolutionized the approach to web apps and servers. With a layer of hypervisor software on a physical server hardware we could install many virtual machines, each with their own operating system (OS) running the app. So now instead of incurring extra server costs with every new application, we could just use an existing, underutilized server to bootstrap a VM and run the app on it.

There are in fact two classification of hypervisor virtualization. There is the Type-1 (native or bare-metal), where the hypervisor software is the closest layer to the actual hardware and a guest operating system runs as a process on the host. This model can be implemented in two ways, monolithic and microkernel hypervisor but that is outside of the scope of this post. The other classification is Type-2 (hosted) where the hypervisor software runs on host OS just as other computer programs do and they abstract guest operating systems from the host operating system.

Regardless of the classification, it was all nice and rosy until we take a deeper look into the efficiencies with hypervisor virtualization model. The cons with this model is that we essentially end up with multiple virtual machines that each consume a chunk of the actual physical server resources such as the CPU, Memory and Disk. Then each of these virtual machines need their own dedicated OS that consume infrastructure just in order to run. That eats up the resources and leaves only a little for the actual app. In addition, these machines all need maintenance and operational baggage and overhead that comes with each of them.

Modern Era: Containers

The containers were introduced to fix the most problematic part of hypervisors; the redundant operating systems. What if we could run multiple applications all on a single server that has only one operating system?

Assume we have multiple apps, each one is in a super lightweight piece of software called a container that run on a single server securely sharing the one OS. We can turn each container on and off, upgrade and swap them if need be in a matter of seconds. Now I will not be getting into the details of microservices or containers orchestration here since they are more advanced topics but in short, If we have multiple apps each in a box that carve a piece of the physical machine they run on, we eliminate the big VM and OS overhead that weigh down performance and efficiency.

Docker Technology

Although there are many container technologies out there (i.e. Vagrant or VirtualBox), Docker seems to be the company and the technology most of the dev community talks about. It worth noting that each of these technologies have something proprietary and are more different than alike. However, some people like to say that Docker to containers technology is what VMWare was to hypervisors.

I will not be going into the details and specifics about Docker in this post. The only thing to mention is that Docker has an engine that runs on a server and we can use it to create, launch and manage containers as lightweight processes. The containers can be ported and managed through API and some aggregator dashboards as well. More on Docker framework on future posts.

Containers Downside

They say everything comes with a price. The containerization technology and container frameworks like Docker are new and fancy, with lots of benefits in terms of efficiency. They promise fast lightweight deployment for high density and scalability apps. However, they also have disadvantages. Let’s tackle a few real quick here:

No One-Size-Fits All

Even though containers provide versatility, they are not a universal replacement for virtual machines. They are ideal for microservice-type application development so they can be scaled easily instead of deploying a full application with every iteration.

However, some applications simply need to be in one piece and there are no need in scalability and fast deployment for them. There are monolithic applications that run perfectly fine on a VM and containerization does not add any value to it.

Not Self-Contained

Containers run on top of a physical OS and they share much of the underlying kernel, binaries and libs. Hence, moving one container from an ecosystem to another is virtually close to impossible. On the contrary, VMs are naturally self-contained since they include their unique OS, drivers and application components. They can also be easily migrated to another hypervisor as long as it’s suited.

The hypervisor-based VMs provide a high level of isolation since they are self-contained and almost nothing extends beyond the scope of a VM. This means that any harm to one VM is barely affecting the others. However, since containers share the same OS kernel and components with a usually a root access level in Linux environment in order to run in first place, they can cause security flaws by propagating an attack to OS layer.

Hard to Manage

The VMs have their definite life-cycle and maintenance approaches and it’s not easy to spin up one and forget about it. Also the technology has been around for decades now so there are plenty of tools out there to manage them.

On the contrary, containers are new and there is a shortage for necessary tools to administer them properly. The nature of containers and microservices architecture requires many of them to run simultaneously where each can technically consume a slice of physical machine resources. This combined with lack of appropriate tools to monitor and manage them, can result in having containers consuming system resources that we spun up to scale and then forget to shut down when we scaled down.