The use cases for Containers versus Virtual Machines have been discussed online for a long time. Everyone has their own views and opinions; some support pure Containers, some support pure VMs, and some support Containers on VMs. This article will introduce Container vs VM from a personal perspective and discuss their appropriate use cases.
Table of Contents
Container
Containers have surged in popularity over the past five years, thanks to their lightweight nature and the flexibility of rapid deployment. Instead of virtualizing the entire hardware, Containers use cgroups and namespaces to isolate host OS resources, which is also referred to as OS-level virtualization. Containers share the host's kernel and only contain their own independent binaries and libraries, making them much faster than VMs in terms of image size and startup speed.
Advantages of Containers:
- Small Image Size: Because it shares the kernel with the host, only the necessary OS components and libraries are required.
- Speed: Deployment is extremely fast, usually taking only a few seconds to spin up a container.
- Portability: With the correct kernel, containers can be easily moved across different hosts or environments.
- CI/CD: Due to their portability and speed, containers are easier to set up in CI/CD pipelines compared to VMs.
- Lifecycle Management: Updating a container only requires restarting it with a new image.
Challenges to address:
- Security: Sharing the kernel with the host makes it less secure than virtualizing the entire hardware.
- No OS Choice: Also because the host kernel is shared, it is impossible to run a different kernel in each container.
- Complex Networking: Containers are typically deployed as microservices, making network connectivity between components more complex.
VM
Compared to containers, VMs are a older and more mature technology. A VM virtualizes the entire hardware layer and installs an OS on top, making it function more like an independent system.
Advantages of VMs:
- Full System Virtualization: This makes using a VM no different from a bare-metal server, allowing for more intuitive operation.
- No Application Refactoring: Since the usage is identical to a bare-metal server, there is no need for major architectural changes to the application.
- Security: Since the entire hardware layer is virtualized, security and isolation are much better than with containers.
- OS Flexibility: You can freely choose to install different operating systems on a VM.
Disadvantages:
- Size: VM images are large, typically exceeding several gigabytes.
- Startup Speed: VMs can take several minutes to boot, making them less ideal for scenarios requiring rapid scaling to meet demand.
- Performance: Due to the hardware virtualization layer, VMs experience some performance overhead compared to bare-metal servers.
When to Use
Container
Before using Bare-metal Containers, you should evaluate the following conditions:
- Microservices-based Applications: Best practices for using containers involve adopting a microservices architecture.
- Running Trusted Code: Running trusted code helps prevent the exploitation of various kernel vulnerabilities.
- Robust Bare-Metal Deployment: Containers still need to run on bare-metal servers with an operating system, which requires a comprehensive bare-metal provisioning mechanism.
- No Special Networking Requirements: Current Container Orchestration Engines like Kubernetes have limited support for specialized networking needs, such as multiple network interfaces, due to CNI specification constraints.
Bare-metal provisioning has also been a rapidly developing direction in OpenStack recently. The newly released Rocky version of Ironic has added many practical features. Those interested can read: Everything you need to know about the OpenStack Rocky release
Virtual Machine
As for VMs, there are quite different conditions that need to be evaluated.
- No Need for Rapid Scaling: VMs are significantly slower to provision than containers. They are less effective than containers for rapid scaling to handle sudden load spikes.
- Running Untrusted Code: It is recommended to run untrusted code on VMs, as they provide superior isolation. This is why public clouds still utilize a VM layer; service providers cannot verify the code users intend to run.
- Requirement for Hard Multi-tenancy: Hard multi-tenancy has not yet been fully implemented in Container Orchestration Engines.
- Specialized Networking Requirements: VMs are more mature in handling applications that require dynamic hot-plugging of network interfaces or multiple NICs.
Currently, the primary demand for VMs remains in traditional applications and public clouds. The former is because they are not based on microservices architecture, making containers less meaningful; the latter is a choice driven by considerations of user isolation and system security.
Somewhere in the Middle
Kata Containers
Kata Containers This is an open-source project started last year, aiming to provide lightweight and fast VM-based containers. Unlike standard containers that use namespaces for isolation, Kata places containers within lightweight VMs to enhance security, aiming to strike a balance between speed and security.
Kata Containers provides isolation through lightweight VMs, allowing untrusted code to run while achieving speeds close to containers. It serves as a hybrid solution between VMs and containers. While there aren't many high-volume use cases in the community yet, it is a technology worth exploring and testing in various environments.
Conclusion
In most cases today, VMs still serve as the foundation for infrastructure, while containers serve as the foundation for applications. Both containers and VMs have their ideal use cases, and they currently coexist and complement each other.
Finally, the world of software is like love: there is no single best solution, only the one most suitable for a specific application. Choosing the solution that best fits your needs is the right approach; don't just jump on the bandwagon of whatever is currently trending.
Reference
Kata Containers
To containerize or not to containerize, that is the question—or, Containers vs VMs: the eternal debate
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
