Containers vs. Virtual Machines – Making an Informed Decision

In this article, we’re going to address the differences between virtual machines and containers. We’ll explore each one and then take a deep dive into the key differences between them. By understanding how they compare in terms of cost, security, and performance, you’ll be better prepared to make the right choice for your applications.

Virtual Machines

The term “virtual machines,” or VMs, refers to emulations of physical computers using a process known as virtualization. Some examples of cloud services that use this technology are:

• Amazon Elastic Compute Cloud (EC2)
• Azure Virtual Machine
• Google Compute Engine

At the core of virtualization is a software application known as a hypervisor. When you install a hypervisor on a physical server, it adds a layer that allows multiple operating systems to exist on the same physical server. These operating systems function as independent computers, accessing the underlying resources such as processing, memory, and network access through the hypervisor.

VMs typically resemble physical servers with a complete operating system and the ability to run multiple applications simultaneously. When we describe VMs, it’s usually in terms of gigabytes, number of virtual processors, and allocated memory. A VM could reasonably host both a web or application server and a backend database on the same instance. A new VM can be provisioned and running within a few minutes.

Containers

Containers are another form of virtualization, but with a much smaller footprint along with faster deployment and startup times. While the technology to support containers has been around for several decades, it didn’t gain widespread acceptance until the arrival of Docker in 2013. In addition to Docker, users can also now choose from other container technologies like Kubernetes and OpenShift to deploy and manage containerized applications.

In place of a hypervisor, containers use a container engine installed as a service on the host server’s operating system. The container engine manages access to resources on the host machine. Because each container shares resources from the host server’s operating system, the container images are significantly smaller than VM images. 

We generally measure containers in terms of megabytes, and their use in cloud environments aids many organizations in implementing microservices architectures. A container will usually only contain a single service with a specific function, and it can be deployed and running in a few seconds. Containers are especially useful in scalable environments where the system can add additional instances of the same service as demand increases. If a container fails, the container engine can destroy and replace the failed container, making for a resilient and fault-tolerant system.

Key Differences

We’ve already covered some of the more apparent differences between VMs and containers. Containers are smaller, quicker to deploy, and can support scalable and fault-tolerant systems. VMs, on the other hand, can perform multiple resource-intensive tasks simultaneously on a single instance, and you could consider them more durable and longer-lasting. 

One critical problem that containers help to address is that of environmental consistency. In traditional development, there can be differences in the version of the operating system and configuration between the development environment and the production environment. When engineers build solutions with containers, they create a container that includes all dependencies. Engineers can reasonably expect that container to perform the same on a development workstation as in a production environment. 

Pros and Cons Deep Dive

The differences cited above provide a clear contrast between VMs and containers, and you could draw conclusions about which one might be best suited to your needs based on your system’s architecture and design. However, there are additional factors to consider that may not be immediately apparent. We’re going to take a deeper dive into some of these factors next.

Costs

There are a couple of different ways to address the difference in costs between containers and VMs. Either way, you’ll need an environment to support your application. If your application experiences significant changes in load, you may benefit from expanding and contracting the size of your environment based on those changes. In that case, containers would provide an advantage both in terms of scalability and cost.

However, the cost for the support and development of your application will have a more significant impact on your expenses than hosting. If you’re developing a cloud-native application from scratch and your engineering staff has experience developing and deploying microservices architectures using containers, containers would be the obvious choice.

Suppose you need to support a legacy application that will meet your users’ needs now and in the future. In that case, you may be better off continuing to host the application using VMs, or migrating from your datacenter to VMs with one of the public cloud providers if you want to pursue a cloud-based strategy. You would also want to consider the expertise and training of your existing IT staff as well as the cost of training or hiring additional help if required.

Rearchitecting and rebuilding an application to take advantage of the benefits offered by containers can be a costly endeavor. While agile development, CI/CD, and DevOps practices can improve your odds of success, there is still an element of risk. Your organization should perform a thorough analysis before embarking on such an endeavor.

Security

Even the most cost-effective and performant cloud architecture isn’t worth it if you can’t keep your system secure. VMs and container environments present different challenges when it comes to security. One such example is the different ways in which VMs and containers implement segmentation between instances.

For VMs, the hypervisor maintains a firm segmentation boundary. This boundary prevents one VM from interacting with another VM on the same host or with the underlying hosts. While segmentation attacks may still occur, hypervisor technology strictly enforces this boundary, making these attacks unlikely.

The host operating system (OS) maintains the segmentation boundary for containers. The OS uses the namespaces and cgroups feature to create logical environments, keeping processes, files, and network states associated with one container and invisible to others. As this relies on the features in the underlying OS, you may run into problems with older versions, and there is an added level of complexity that makes security more challenging. Engaging experienced administrators to secure and harden the host machines will reduce the risk of vulnerabilities. You can also enlist the help of industry experts and tools to further secure and protect your container images and the host machines.

Configuration drift is another important consideration when comparing security. Containers are usually destroyed and redeployed frequently, reducing the chance that settings may change as the environment ages. The configuration for a container is also documented in the container manifest, making it easy to observe and verify the container’s configuration as well as which dependencies it includes. Conversely, VMs may contain complex configurations that are not always clearly documented, and given their more persistent nature, they are more prone to configuration drift.

Last but by no means least, vulnerability scans are an effective tool to prevent the inclusion of potentially dangerous or vulnerable code in new deployments. Third-party tools are available for containers and applications alike. As with configuration, though, containers present a less complex target for these scans when compared to VMs, which may contain multiple applications as well as supporting libraries and software.

Performance

Performance comparisons between containers and VMs can be challenging due to variables introduced by system design and configuration. From the perspective of access to resources on the host machine, VMs rely on virtualized resources which add to performance overhead. At the same time, containers can have direct access to the host system’s resources, such as graphic cards. With that said, hypervisors and container engines continue to improve, and there is not a dramatic performance gain to be realized from switching from VMs to containers.

One area where containers outperform VMs is in startup time, which, as we mentioned above, can be a few seconds for a new container, compared to a few minutes for a VM. Containers gain another advantage from the way in which the container engine optimizes resource usage between all of the containers it supports. VMs require the permanent allocation of most resources when starting, which may tie up resources in VMs that don’t require them while preventing those resources from being used by another VM on the same host that is experiencing high load.

Finally, VMs require installing an operating system on each instance, resulting in a large storage allocation for duplicated components, libraries, and services on the host machine. All containers hosted on a machine rely on that machine’s operating system. This design reduces redundancy and frees up resources to be better allocated.

Making the Right Decision

Given all the different factors above, choosing the right approach for your organization can be challenging. What is optimal for one organization might not be suitable for another. Containers do provide advantages for cloud-native applications that can take advantage of the benefits they offer. Virtual machines, meanwhile, are an established and proven technology that can support legacy applications in a performant and cost-effective way.

The beauty of the cloud is that this decision doesn’t have to be one or the other. For example, you may discover that hosting your containers on virtual machines allows you to take advantage of the benefits of both. You might choose to reduce complexity by using an established container platform like AWS Elastic Container Service (ECS) or the Google Kubernetes Engine (GKE). In addition, you might have some purely software-based applications that are good candidates for containerization, while others with specific hardware requirements may function better when deployed on VMs.

Take your time to examine and understand your options. You may also find that your needs change over time, and you can achieve better performance for a lower cost by redesigning your application to take advantage of newer technologies.