Maksym Yemelyanov - stock.adobe.
Bare-metal vs. VM container deployment considerations
Consider your performance requirements, portability needs and what level of isolation and security you want when deploying containers in your environment.
Determining where to deploy containers depends on the type of applications you run. Each application has its own performance specs, portability levels and security recommendations, all of which you should factor into the bare-metal vs. VM decision.
Containers, from initial interest to implementation, progressed at a rapid pace in the market. In fact, containers caught more than a few virtualization administrators off guard with the speed of adoption. The trouble is a lack of understanding on how containers fit in the virtual data center. Containers provide flexibility in that you can deploy them on bare-metal hardware with just an OS or on a hypervisor, such as VMware's ESXi.
When deciding on bare-metal vs. VM deployment, keep in mind that container architecture differs from VMs. A container is an application execution environment that runs on top of a container engine, which sits on an OS. A VM is a software-based computer on a hypervisor. Both instance types have positives and negatives, and it's important to understand them so you can make the most informed decision for your business applications.
Performance requirements
One of the benefits of containers is that they are lightweight and provide fast application performance. A container on bare-metal hardware includes an OS and the container engine. With a hypervisor, you add an abstraction layer to start, but then you also need multiple guest OSes to support container engines. From a performance and resource utilization perspective, containers on bare metal vs. VM win hands down. However, the specific performance gains are difficult to calculate.
Often, you see specs that the hypervisor and guest OSes take an additional 6% to 12% of the resources in a virtual environment, and that can negatively affect container performance. This is absolutely true if your containers run at 100% and you want to max out the density of your containers. But think about whether you actually need that level of performance. You still might see some performance degradation due to the extra software layers of the VM model, but ask yourself if it will affect what you use containers for. Overall, the performance question is valid, but the difference between the two deployment models might not be that significant.
Portability needs
Containers are based on the engine they sit on and are portable in terms of where they can run on their container engine, which is either on premises or in the cloud. The same can be said for VMs. They run on a hypervisor, so in reality, they are just as portable. The key difference here is with vMotion or live migration.
You can migrate containers between engines but not while they're running. VMs can move between hypervisors without an outage. Because containers are stateless, it's easier to shift the workloads from one container to another. Containers depend more on application portability rather than instance portability. Using vMotion is different in that it moves the running VM in its entirety, including all its workloads. Both container and VMs are portable; the difference lies in what exactly you're moving.
Isolation and security
One of the key features of a hypervisor is isolation from malicious code, crashes and performance issues. Although containers have some isolation, they don't offer the same protection that a hypervisor does. The container application is more distributed, which is what offers some level of protection in the event of a failure or security issue. In the case of a hypervisor, you add the VM layer to the security profile but at the possible cost of performance and density of containers.
Neither method is wrong, but they are two different security models. Which one works for you depends on where and how many layers deep you want the security.
Bare metal vs. VM: The verdict
The question of whether it's better to run containers on bare metal vs. VM comes down to where you stand on a couple of key points.
Do you need the top performance and reduced overhead of a hypervisor? If so, then deploying containers on bare-metal hardware might be ideal. That deployment method also increases your density per hardware platform, which sounds great, but in the event of a failure, you lose even more workloads with no ability to use vMotion.
Portability is going to depend on the application. Older applications with less ability to shift workloads might push you into a hypervisor-based container platform, and new applications will favor the bare-metal approach, as they might be able to shift workloads better.
The deciding factor might come down to isolation and security. Adding a hypervisor enables you to take advantage of added security features, such as NSX and microsegmentation. It's not that containers have no security; the hypervisor is simply another layer of security you can add. All of these things help determine where you're going to deploy containers.
