Virtual machines were once the hottest new technology, but now containers are gaining more and more steam in the data center.
By Alastair Cooke
One of the biggest challenges in IT is the sheer range of tools available to solve problems. New tools are developed and implemented rapidly to satisfy business requirements, while old options and techniques pass out of use. It can be hard to keep up with all of the new tools. We often relate new tools to old tools to help understand how they work. Containers are a hot technology that is expected to transform IT just like virtualization was in recent years. Containers are often compared to, and confused with, virtualization. Some of the terms used to describe containers sound a bit like virtualization terms. Are containers the new virtual machines? The bottom line is that containers and virtual machines are very different.
The virtualization technology that has transformed data centers over the last 10 years uses hardware virtualization. A hypervisor delivers virtual hardware to a VM, which then runs an operating system (OS). On top of the OS, you can run one or more applications. The applications don't need to know they are running in VMs. Those applications would run exactly the same on the physical servers that virtualization replaced. Compatibility with existing applications has been important to the rapid widespread adoption of virtualization.
The virtualization host is able to run multiple VMs -- typically, a couple dozen of VMs per host. Creating a VM involves copying tens of gigabytes of data, which takes at least a few minutes. VMs are also typically long-lived, with many having no planned date for decommissioning. Operating system updates, application version updates and patching help maintain VMs. The applications that run in VMs are complex and relatively infrequently updated. If the application inside a VM goes wrong, it is usually analyzed and the fault corrected. The VM will also usually be backed up so it can be restored if it gets broken.
Container products like Docker and Rocket virtualize an operating system rather than the hardware. Inside the container is a single executable service that is a small part of an application. The service is specially written (or modified) to run inside a container and is referred to as a microservice. Microservices provide a relatively simple function from a single piece of executable code.
Applications are made up of a collection of microservices and each provides a small part of the overall application. Multiple copies of a single microservice may be run in many containers, and those containers are linked together with message queuing or load balancing. The individual containers are usually disposable, provided there are enough instances of the microservice running so that the overall application continues to operate. The application itself is built to cope with individual container failure and each container has its own instance of the microservice software code. All of the containers for the same microservice run the same code.
The build process for a container relies on a configuration file that fully describes it. This is usually a combination of the operating system version and the software code that makes up the microservice. Creating a new container instance does not require a large amount of data be copied and only the unique data that the code writes as it starts. Starting a container takes less than a second and may occur several times every minute.
In order to update a container, the configuration file is modified and a new container is created. The out of date containers are then destroyed. New containers can be created to cope with an increase in application load and then destroyed when the load reduces. A faulty container is generally destroyed and recreated to return to an operational state. Containers are not modified to fix them and are never restored from backup. Instead, they are simply deleted and recreated.
An operating system runs inside a VM, and a container runs inside an operating system. The result is that containers can be run in VMs on a virtualization platform. This is one of many possible ways to deploy containerized applications. On the other hand, it is next to impossible to make a VM run inside a container; if achieved, it would deliver little value. I'm sure someone will do it just to have bragging rights.
The table below summarizes the key characteristics of containers and VMs.
Containers and VMs address two very different needs but both will have a place in the future of many IT organizations. Containers have a different specific role and aren't the new virtual machines, per se. Identifying the right place to use each tool is crucial to success. Fundamentally, containers are tiny objects that can be assembled into applications and must be designed and written to run in containers. On the other hand, VMs are a place to run your application and work with applications developed over the last 20 years.
Original Article Posted on TechTarget