Petya Petrova - Fotolia
VMs vs. containers: What Windows admins need to know
VMs have high resource overhead, but they're dependable. Containers can scale dramatically, but they require a different mode of management. Which is right for your workloads?
Virtual machines and containers are both types of virtualized workloads that have more similarities than you may think. Each serves a specific purpose and can significantly increase the performance of your infrastructure -- as long as they are employed effectively.
Microsoft unveiled container support in Windows Server 2016, which might have seemed like a novelty feature for many Windows administrators. But now that containers and the surrounding technology -- orchestration, networking and storage -- has matured on the Windows Server 2019 release, is it time to give containers more thought?
How do you make the decision on when to use VMs vs. containers? Is there a tipping point when you should make a switch? To help steer your decision, let's cover the three key abilities of containers and virtual machines.
Reliability
When it comes to weighing the options, the difference in reliability is one of the first questions any engineer will ask. Although uptime ultimately depends on the engineers and engineering behind the technology, you can infer a lot about their dependability by analyzing the security and maintenance costs.
VMs. VMs are big, heavyweight, monoliths. This isn't a comment about speed, because VMs can be blazingly fast. The reason they're considered monoliths is because each contains a full stack of technology; virtualized hardware, an operating system and even more software are all layered on top of each other in one package.
The advantage of utilizing VMs becomes apparent when you drill down to the hypervisor. VMs have full isolation between themselves and any other VM running on the same hardware or in the same cluster. This is highly secure; you can't directly attack one VM in a cluster from another.
The other reliability advantage is longevity. People have been using VMs in Windows production environments for about 20 years. There are a large number of engineers with vast amounts of experience managing, deploying and troubleshooting VMs. If an issue with a VM arises, there's a good chance it's not a unique occurrence.
Containers. Containers are lightweight and less hardware-intensive because they aren't running a full suite of software on top of them. Containers can be thought of as wrappers around a process or applications that can run in a stand-alone fashion.
You can run many containers on the same VM; due to this, you don't have full isolation in containers. You do have process isolation, but it's not as absolute as it is with a VM. This can cause some difficulties in spinning up and maintaining containers when determining how to parcel out resources.
Additionally, because containers are so relatively new compared to VMs, you might have trouble finding the engineers with a similar amount of career dedication to their management. There are additional technologies to bring in to help with their administration and orchestration, the learning curve to get started is generally seen as higher compared to more traditional technologies, such as VMs.
Scalability
Scalability is the capability of the technology to maximize utilization across your environment. When you're ready for your application to be accessed by tens of thousands of people, scalability is your friend.
VMs. VMs take a long time to spin up and deploy. Cloud technology such as AWS Auto Scaling and Azure Virtual Machine Scale Sets build out clones of the same VM and load-balance across them. While this is one way to reach scale, it's a little clunky because of the VM spin-up time.
For a one-off application, VMs can host it and work well, but when it comes to reaching the masses, they can fall short. This is particularly true when attempting to use non-cloud-native automation to scale VMs. The sheer time difference between a VM deployment and a container deployment can cause your automation to go haywire.
Containers. Containers were built for scale. You can spin up one or a hundred new containers in milliseconds, which makes automation and orchestration with native cloud tooling a breeze.
Scale is so innate to containers that the real question with scale is, "How far do you want to go?" You can use IaaS on AWS or Azure using your own Kubernetes orchestration, but you can even take this one step further with the PaaS technologies such as AWS Fargate or Azure Container Instances.
Manageability
Once you have your VMs or containers running in production, you need a way to manage them. Deploying changes, updating software and even rotating technologies all fall under this purview.
VMs. There are scores of third-party tools to manage VMs, such as Puppet, Chef, System Center Configuration Manager and IBM BigFix. Each does software deployment, runs queries on your environment, and even performs more complex desired state configuration tasks. There are also a host of vendor tools to manage your VMs inside VMware, Citrix and Hyper-V.
VMs require care and feeding. Usually when you create a VM, there is a lifecycle it follows from the spin up to its sunset date. In between, it requires maintenance and monitoring. This is contrary to newer methodologies such as DevOps, infrastructure as code and immutable infrastructure. In these paradigms, servers and services are treated like cattle, not pets.
Containers. Orchestration and immutability are the hallmarks of containers. If a container breaks, you kill it and deploy another one without a second thought. There is no backup and restore procedure. Instead of spending time modifying or maintaining your environment, you fix a container by destroying it and creating a new one. VMs, because of the associated time and maintenance costs, simply can't keep up with containers in this respect.
Containers are tailored for DevOps; containers are a component of the infrastructure that treats developers and infrastructure operators as first-class citizens. By layering the new methodology on new technology, it allows for a faster way to get things done by reducing the complexities tied to workload management.
Which is the way to go?
In the contest of VMs vs. containers, which one wins? The answer depends on your IT team and your use case. There are instances where VMs will continue to have an advantage and others where containers are a better choice. This comparison has just scratched the surface of the technical differences, but there are financial advantages to consider as well.
In a real-world environment, you will likely need both technologies. Monolithic VMs make sense for more solid and stable services such as Active Directory or the Exchange Server platform. For your development team and your homegrown apps utilizing the latest in release pipeline technology, containers will help them get up to speed and scale to the needs of your organization.
