What’s the Diff: VMs vs. Containers

October 15, 2021 by Molly Clancy // 18 Comments

Both VMs and containers use virtualization to help you maximize available computer hardware and software resources. Containers have been around for a while, but their broad adoption over the past few years has fundamentally changed IT practices. VMs, on the other hand, have been very popular for some time, and continue to be in data centers of all sizes.

As you approach architecture decisions including running services and applications in the cloud, you need to understand these virtualization technologies. Today, we’re digging into how they work, how they compare to each other, and how to use them to advance your digital transformation.

First, the Basics: Some Definitions

What Is Virtualization?

Virtualization is the process of creating a simulated computing environment that’s abstracted from the physical computing hardware—essentially a computer-generated computer. Virtualization allows you to create multiple, virtual computing instances from the hardware and software components of a single machine. Those instances could be a computer in the traditional sense or a storage repository, application, server, or networking configuration.

What Is a Hypervisor?

The software that enables virtualization is called a hypervisor. It’s a lightweight software layer that sits between the physical hardware and the virtualized environments and allows multiple operating systems (OS) to run in tandem on the same hardware. The hypervisor is the middleman that pulls resources from the raw materials of your infrastructure and directs them to the various computing instances.

VMs and Containers

What Are Virtual Machines?

The computer-generated computers that virtualization makes possible are known as virtual machines (VMs)—separate computers running on hardware that is actually contained in one physical computer.

Each VM requires its own OS. The OS and any applications running on an individual VM share hardware resources from a single host server, or from a pool of host servers. Thanks to the hypervisor, the hardware resources are virtualized and each VM is isolated from its neighbors.

Since the advent of affordable virtualization technology and cloud computing services, IT departments large and small have embraced VMs as a way to lower costs and increase efficiencies.

VMs, however, can take up a lot of system resources. Each VM runs not just a full copy of an OS, but a virtual copy of all the hardware that the operating system needs to run. It’s why VMs are sometimes associated with the term “monolithic”—they’re single, all-in-one units commonly used to run applications built as single, large files. (The nickname, “monolithic,” will make a bit more sense after you learn more about containers below.) This quickly adds up to a lot of RAM and CPU cycles. They’re still economical compared to running separate actual computers, but for some use cases, particularly applications, it can be overkill, which led to the development of containers.

Benefits of VMs

• All OS resources available to apps.

• Well-established functionality.
  • Robust management tools.
  • Well-known security tools and controls.

• The ability to run different operating systems on one physical machine.
• Cost savings compared to running separate, physical machines.

Popular VM Providers

What Are Containers?

With containers, instead of virtualizing the underlying computer like a VM, just the OS is virtualized.

Containers sit on top of a physical server and its host OS—typically Linux or Windows. Each container shares the host OS kernel and, usually, the binaries and libraries, too. (See below for definitions if you’re not familiar with these terms.) Shared components are read-only.

Sharing OS resources, such as libraries, significantly reduces the need to reproduce the operating system code—a server can run multiple workloads with a single operating system installation. Containers are thus exceptionally light—they are only megabytes in size and take just seconds to start. What this means in practice is you can put two to three times as many applications on a single server with containers than you can with a VM. Compared to containers, VMs take minutes to run and are an order of magnitude larger than an equivalent container, measured in gigabytes versus megabytes.

Container technology has existed for a long time, but the launch of Docker in 2013 made containers essentially industry standard for application and software development. They solve the problem of environment inconsistency. Developers generally write code locally, say on their laptop, then deploy that code on a server. Any differences between those environments—software versions, permissions, database access, etc.—leads to bugs. With containers, developers can create a portable, packaged unit that contains all of the dependencies needed for that unit to run in any environment whether it’s local, development, testing, or production.

Microservices architectures for application development evolved out of this container boom. With containers, applications could be broken down into their smallest component parts or “services” that serve a single purpose, and those services could be developed and deployed independently of each other instead of in one monolithic unit. For example, let’s say you have an app that allows customers to buy anything in the world. You might have a search bar, a shopping cart, a buy button, etc. Each of those “services” can exist in their own container, so that if, say, the search bar fails due to high load, it doesn’t bring the whole thing down. And that’s how you get your Prime Day deals today.

Container Tools

Linux Containers (LXC): Commonly known as LXC, these are the original Linux container technology. LXC is a Linux operating system-level virtualization method for running multiple isolated Linux systems on a single host.

Docker: Docker started as a project to build single-application LXC containers, introducing several changes to LXC that make containers more portable and flexible to use. It later morphed into its own container runtime environment. At a high level, Docker is a Linux utility that can efficiently create, ship, and run containers.

Kubernetes: Kubernetes is not a container software, per se, but rather a container orchestrator. In this cloud-native, microservices world, when some apps run hundreds or thousands or even billions of containers, Kubernetes helps automate management of all of those containers. It can’t function without a tool like Docker in tandem, but it’s such a big name in the container space it wouldn’t be a container post without mentioning it.

Benefits of Containers

• Reduced IT management resources.
• Faster spin ups.
• Smaller size means one physical machine can host many containers.
• Reduced & simplified security updates.
• Less code to transfer, migrate, and upload workloads.

What’s the Diff: VMs vs. Containers

The virtual machine versus container debate gets at the heart of the debate between traditional IT architecture and contemporary DevOps practices.

VMs have been, and continue to be, tremendously popular and useful, but sadly for them, they now carry the term “monolithic” with them wherever they go like a 25-ton Stonehenge around the neck. Containers, meanwhile, pushed the old gods aside, bedecked in the glittering mantle of “microservices.” Cute.

To offer another quirky tech metaphor, VMs are to containers what glamping is to ultralight backpacking. Both equip you with everything you need to survive in the wilds of virtualization. Both are portable, but containers will get you farther, faster, if that’s your goal. And while VMs bring everything and the kitchen sink, containers leave the toothbrush at home to cut weight. To make a more direct comparison, we’ve consolidated the differences into a handy table:

VMsContainers Heavyweight.Lightweight. Limited performance.Native performance. Each VM runs in its own OS.All containers share the host OS. Hardware-level virtualization.OS virtualization. Startup time in minutes.Startup time in milliseconds. Allocates required memory.Requires less memory space. Fully isolated and hence more secure.Process-level isolation, possibly less secure.

Uses for VMs vs. Uses for Containers

Both containers and VMs have benefits and drawbacks, and the ultimate decision will depend on your specific needs.

VMs are a better choice for running apps that require all of the operating system’s resources and functionality when you need to run multiple applications on servers, or have a wide variety of operating systems to manage. If you have an existing monolithic application that you don’t plan to or need to refactor into microservices, VMs will continue to serve your use case well.

Containers are a better choice when your biggest priority is maximizing the number of applications or services running on a minimal number of servers and when you need maximum portability. If you are developing a new app and you want to use a microservices architecture for scalability and portability, containers are the way to go. Containers shine when it comes to cloud-native application development based on a microservices architecture.

You can also run containers on a virtual machine, making the question less of an either/or and more of an exercise in understanding which technology makes the most sense for your workloads.

In a nutshell:

• VMs help companies make the most of their infrastructure resources by expanding the number of machines you can squeeze out of a finite amount of hardware and software.
• Containers help companies make the most of the development resources by enabling microservices and DevOps practices.

Are you Using VMs, Containers, or Both?

We will explore this topic in greater depth in subsequent posts. If you are using VMs or containers, we’d love to hear from you about what you’re using and how you’re using them.