By Engine Yard
Before the rise of containerization, virtual machines were the way to go if you needed to isolate environments within a physical infrastructure.
However, when Docker Inc. released its containerization software in 2013, the spotlight shifted to containers.
Since then, we’ve seen an increase of interest in containers, and changing the cloud computing landscape in the process. More and more developers are interested in the agile development process offered by containers.
Both virtual machines and containers are designed with the concept of optimizing resources from an existing physical infrastructure in mind.
However, how do they differ? Is one superior over the other? Which one should you use for your next project?
In this post, we try to answer these questions by getting to know more about containers and virtual machines.
A virtual machine (VM) is an isolated environment that emulates a computer system with access to physical hardware resources.
Virtual machines run on top of the hypervisor software, which imitates the physical infrastructure and divides the resources into multiple virtual machines. The hypervisor is also referred to as the host machine or a virtual machine monitor.
Each VM seems to be running on bare-metal hardware, giving the impression that there are multiple PCs running when they are actually supported by individual physical servers.
VMs tend to be bulky and be many gigabytes in size because each VM contains its own guest operating system, kernel, binaries, libraries, and its application.
Containers create isolated environments in a physical server by virtualizing the host operating system and running packaged applications on top of it.
Instead of virtualizing the hardware like virtual machines, containers virtualize the OS. It’s built on top of a host OS kernel and usually shares its libraries and binaries.
Because it shares most of its necessities, containers only pack the application and its dependencies. They’re much lighter than VMs and only megabytes in size.
There are a lot of containerisation and orchestration platforms. The most popular set up commonly used for complex applications are the pairing of Docker as the containerisation platform and Kubernetes, a container orchestration platform developed by Google.
A container consists of a master node, worker nodes and pods. A master node is the control that connects your requirements with the rest of the system. Pods are where your containers are located, while worker nodes are where pods will be deployed to.
After understanding what containers and virtual machines are, now it’s time to compare the characteristics of both virtualization technologies.
As a part of a distributed system, containers are highly portable.
Because containers pack microservices and their dependencies in a small-sized package, it’s easy to move containers around, even across environments, such as the public cloud, private cloud, and hybrid cloud, as well as the multi-cloud and bare-metal environments.
• Effective resource usage
Code packaged within containers share most of the dependencies needed to run the containers, including an operating system, libraries, and frameworks.
Unlike in virtual machines, there’s only one copy of necessary files in each hardware, leading to more effective resource usage. This also results in a lighter container, which means you can fit more containers within a physical server.
• Easier to maintain
As containers use a microservices-based architecture, your code is broken down into manageable pieces that can be handled individually. Hence, you can update and maintain a container without worrying it will affect other parts of your application.
• Highly Scalable
Container orchestration platforms are created to help you manage your containers. Container orchestrators, like Kubernetes or Docker Swarm, automate most of your container management process, including scaling, networking, and deployment.
Containerized applications are highly scalable, and they can scale up and down quickly by spinning up new nodes and/or pods when the needs call for it.
• Lacking Security measures
Containers provide lightweight isolation from the host OS and containers within the same system. This leads to a weaker security boundary compared to virtual machines.
However, mature container users are paying more attention to security, as they try to improve collaboration between DevOps and Security, according to StackRox.
• Runs only one OS
This can be a benefit if you only use one OS, but if you need to be able to use it across different OS’s this is a negative. You can run an earlier version of the same OS using lightweight virtual machines.
Popular container providers:
• RedHat Openshift
• Google Kubernete Engine
• Linux Containers (LXC, LXD, CGManager)
• Windows Server Containers
• Hard security boundaries
VMs provide more isolation between neighboring systems, as you’re using a separate operating system from other machines in the same physical server. Whereas in containers, you’re operating within one OS, and flaws can affect the entire system.
The complete isolation in VMs results in better security, and vulnerabilities that are harder to exploit. If you’re not in control of the environment you’re in, using VMs, which has a stronger boundary is preferable.
Even so, leading container providers are dedicating more effort into security over time, so you might see containers with the same level of security as VMs soon.
• Can emulate multiple OS
As you can run any operating system you want within a virtual machine, you don’t need to buy another hardware every time you need a different OS.
For example, when you need to simulate and test your applications across different operating systems to gain a clearer view of your application’s capability, using a virtual machine saves you from buying multiple different hardware.
• More resources
The resources allocated for a virtual machine are far more than what’s allocated for containers. That’s why VMs are more suitable for resource-intensive tasks. Tasks with larger sizes and a long lifecycle are more suitable to use with VMs rather than containers.
You can run resource-intensive tasks on containers. However, you need to consider the cost of using containers as opposed to using a VM. Line up your requirements beforehand and do some research to discover which option will be more cost-effective for your application.
• Not as portable
Virtual machines are gigabytes-sized chunks of software.
Naturally, it’s harder to move a virtual machine when compared to a container, because the applications run on a virtual machine that is highly dependent on the OS and the emulated hardware it runs on.
Moving virtual machines across data centers or the cloud will be harder than if you’re using containers.
• Ineffective resource usage
Often, the resources provided by virtual machines are too much for running a single application.
However, once a VM is assigned to a resource, it takes up the whole space, even when it needs less. This creates idle power that you can use elsewhere if your planning is inaccurate.
Furthermore, VMs don’t only copy the operating system instances, it also contains libraries, binaries, and copies of the virtual hardware needed by the OS. Repetitive files suck up a large part of the RAM and CPU resources of the servers.
• Harder to maintain the OS
As there are multiple operating systems in one VM, you need to update and maintain each OS separately. This is a time consuming and exhausting task, especially if you have multiple VMs.
Popular VM Providers
VMs and containers have their own use cases. To decide which method you should use, you should look at the requirements of your application.
The container technology is rising in popularity thanks to its high scalability, effective resource management, and agile development cycle.
A recent study shows that the adoption of application containers will grow 30% annually by 2027.
Here are a few scenarios containers would be perfect for:
• Your application has a multiservice architecture
• You want to minimize the number of servers you work on
• Your project moves through several different environments
• You’re building cloud-native applications
• Your project is developed on a similar environment as production
On the other hand, virtual machines are far from obsolete. It’s still a reliable way to store your application securely and have a longer life cycle than containers.
Here are a few cases where virtual machines work well:
• Your application has a monolithic architecture
• You need to run different operating systems
• You need a platform with persistent storage
• You need to separate systems for security purposes
• You need the full functionality an operating system can offer
You can also combine both virtual machines and containers to create a more suitable setup for your application. Combining VM’s flexibility and container’s efficiency also improves isolation and functionality.
Virtual Machines often become the host OS for containers.
VMs and containers have the same goal: reduce overhead costs, agile software development, and optimizing resources. However, they take a different approach to accomplish these goals.
VMs and containers have their own use cases, and sometimes it’s tricky to figure out which option you should use for your application.
Get some help from the experts. Here at EngineYard, we help you deploy your containerized application using AWS hosting and support from an experienced DevOps team.
Consult an expert DevOps team before you made a costly mistake for your deployment options.
Contact us if you want a painless deployment and continuous support for your application.
Originally appeared on Engineyard.com