When people discuss cloud computing, two terms are frequently used: virtual machine and containers. This is especially true in the era of multicloud, when a cross platform strategy is essential.
The two technologies share common ground: both virtual machines and containers are software technologies, and both run in a virtualized environment. After that they differ in operation, size, management, use cases and other factors.
Let’s look at virtual machines and containers.
Virtual Machines: a Self-Contained Instance
A virtual machine is an entire instance of an operating system, usually Windows or Linux, in a self-contained portion of a server’s memory that is walled off from the rest of the system.
Consolidate tasks
Virtual machines take advantage of the high memory capacity and multiple cores in CPUs to consolidate numerous applications and tasks onto one physical piece of hardware. When virtualization first became popular a decade ago, that was its primary use.
At the time, it was not uncommon for data center operators to move the apps and tasks from ten or more 32-bit single-instance servers onto one virtualized physical server. That was a huge step forward in efficiency.
Mature technology
All of the major vendors of hypervisors – VMware, Microsoft, Citrix, and Red Hat – offer their own brand of virtual machines. The technology is very mature.
For example, should a physical server fail, the hypervisor will automatically move the virtual machines running on it to another physical server without any human intervention required. Ten years ago, you had to do this manually.
Virtual machines also provide a hardware abstraction layer (HAL) so developers can write apps without having to worry about compatibility with the underlying hardware.
Containers: Only What’s Needed for Travel
Containers load just enough of the kernel and runtime code to operate the app in the container, instead of loading a full and complete instance of Windows or Linux, as do virtual machines. This lighter framework enables them to be flexible enough to move easily between operating environments.
Primarily Linux
Containers hold just one app and just enough operating system to execute that app, so that requires some extra whittling down of the core OS to fit in the smaller footprint of the container. Because of this, containers are primarily a Linux phenomenon, since it is open source and modifiable. Microsoft does offer Windows Containers, but they are newer than Linux containers and not as mature of a technology.
Orchestration platforms
Because of their small, simple structure, containers need to be managed. This is done through what is called an orchestration platform. Container orchestration manages the lifecycles of containers, since they are frequently launched and shut down more often than VMs.
Orchestration does, but is not limited to, provisioning and deployment of containers, availability and failover, scaling up or removing containers, moving containers to a new host should there be a crash or heavy load, and other resource allocation.
The first to market was Docker, with the Swarm platform for container management. There are also Apache Foundation’s Mesos and Marathon, which are a bit more complex than Swarm.
The gold standard for container orchestration is Google’s Kubernetes. It became popular in DevOps environments for delivering Platform-as-a-Service that abstracts the hardware layer from developers. It’s also extremely portable, running on Google Cloud Platform, Amazon Web Services, Microsoft Azure, and on-premises data centers.
Virtual Machines vs. Containers: Key Differences
Size
The major difference between virtual machines and containers is size. A container can be as small as 10MB while a VM can be as large as a few gigabytes in size. Obviously this impacts memory – the same physical server can hold many more containers than VMs.
Structure
There is a significant difference in the structure of the two technologies. A virtual machine is fully contained and has all of the parts of the operating system and is run with hardware support. Containers require an underlying operating system that provides the basic services to all of the containerized applications, using virtual-memory support for isolation. So you need a full blown OS no matter what you run, VM or container, it’s just how it is structured. The OS runs under the container layer while it is in the VM.
However, they work together
Because of their different natures, containers and virtual machines don’t compete with each other, but more likely compliment one another. You would use both in a complex enterprise, with the VMs for larger, more complex apps, and containers for small, simple, single-purpose apps.
Pros and Cons of Virtual Machines and Containers
Virtual Machines Offer More Resources
Virtual machines have several advantages over containers. Because you are using the full OS and not a custom, whittled down version, you have the full strength of the operating system. That means all OS resources are available and you have a full suite of management and security tools. In short, you have the full OS, whether it’s Windows, Red Hat, Ubuntu, or some other flavor of Linux.
Virtual Machines Require Longer Boot Time
Among the downsides to VMs is, of course, their large size. On a resource-constrained server, that will be limiting. Because of the size difference, virtual machines may take several minutes to boot up while containerized applications can be started almost instantly. That means containers can be loaded when they are needed and then closed when they are no longer needed, freeing up resources on their hosts.
Virtual Machine Security Challenges
Security can be an issue, in theory, on the public cloud because you are co-existing with other customers and have no idea who they are. Or who the cloud employees are. There is the ever-present fear of snooping in VMs, trying to extract information or data from a neighbor.
But the main risk to security is more likely accidents. For example, you may spin up a virtual machine with full encryption or other security protections on AWS. But then due to an overload of processes, your VM gets moved to another server or even another physical location and the security aspects are not preserved. This can be mitigated by doing proper and repeated security checks.
Another potential security problem would be VM sprawl, a common phenomenon where users spin up many VMs and don’t shut down the old ones. Then you run the risk of too many VMs that can be effectively managed. Perhaps not all security patches are applied. This is a management issue, not a technological one, so it falls to you to prevent the problem, not your cloud provider.
Containers and Communication Control
With containers, in some cases all of the containers can communicate with each other by default. This means if a malicious user or program gets control of one container, it has control of all of them. Developers should only allow intercommunication between containers that absolutely need it and limit what kind of communication they allow.
Because you create your own operating environment in a container, it falls to you to do kernel-level patching and apply all updates to the operating environment, which can increase your workload. Some kind of patching policy for containers needs to be in place and enforced.
Containers and Linux Subsystems
Because containers don’t contain a full OS, they access a lot of the Linux kernel subsystems. Docker uses libcontainers as its container technology and it accesses important namespaces outside the container. So anyone with full privileges within the container can access the underlying OS and therefore, start poking around outside the container, perhaps snooping on other containers. The fix for this is very careful and thorough configuration of the containers to make sure they are locked down.
Virtual Machine and Container Use Cases
Despite their similarities, a fundamental difference in usage exists between the containers and virtual machines. Virtual machines are meant for virtual environments, while containers do not require a hypervisor and use the underlying operating system on which they run.
Virtualized Environments
In a virtualized environment, you run multiple operating systems on a hypervisor that manages I/O on one machine. In a containerized environment, it’s not virtualized and no hypervisor is used. That’s not to say you can’t run a container in a VM – you can. But it’s not the most efficient way to do it.
So even though containers run on a single OS instance, it’s like mini-virtualization because you can run dozens or hundreds of containers on one physical system. It’s virtualization without the hypervisor, and that can be a good thing. This is because hypervisors suffer from performance limitations and also block access to certain components in the server, such as the networking controller.
DevOps
That is one of the main reasons that DevOps environments prefer containers for their develop-test-build. Their containers perform faster than VMs, can be spun up and down a lot faster, and have better access to system resources.
The main benefit of the container is their small size and the ability to run hundreds or even thousands on a server vs. a few dozen virtual machines. This is predicated on another advantage of containers: their greater modularity over virtual machines. An app can be split among multiple containers, in a technology called microservices – clearly, containers and microservices work well together. This combination helps isolate problems and any potential crashes or bottlenecks. It is a lot easier to localize a problem than if it were a large, monolithic application.
More Secure Environments
Virtual machines are ideal for a more secure environment since everything is contained in the VM. A container frequently has to communicate with the underlying OS or other containers, which can present a security risk. In a VM, everything is in the same silo. So if you need a completely siloed, walled off operating environment, the VM is the way to go.
Older Systems
Virtual machines also allow for hosting of older versions of an operating system. For example, an application written years ago, for an older operating system, might not run in a newer generation of the OS and you might not have the resources to modernize it. So run the old OS in a virtual machine and let the app run unchanged.
The Future
Containers need the most work technologically to reach maturity, though the technology is advancing at a rapid clip. VMs are more mature and, because of their nature, are more secure and more manageable.
Container technology, particularly security, is still evolving. It also needs improvements in the areas of load balancing, trusted connections, and other areas that are mature in full blown operating systems. This is what happens when you take an OS and whittle it down to a few megabytes. You have moments of “oh, I needed that” about things you may have thrown away.
Looking forward, expect continued maturation of the container products from Docker and Google, while VMs will continue to focus on things like performance and portability across servers. In any case, both technologies will continue to play a key role in cloud computing.
Containers vs. Virtual Machines at a Glance
SEE ALL
DATA CENTER ARTICLES