Using Containers on Virtual Machines, Bare Metal, or Both?

When it comes to container deployment, you can take a few different approaches. You can run containers on virtual machines (VMs), bare metal, or both. But what one is better?

The debate over whether to use containers on virtual machines or bare metal really comes down to speed and efficient use of hardware resources versus isolation and ease of portability. Let’s take a look at the advantages and disadvantages of both.

Containers on Bare Metal

There are plenty of advantages to running containers on bare metal servers. For one thing, this eliminates the overhead of the host operating system, or both the hypervisor and the guest operating system if running the container in a virtual machine.

Containers running on bare metal utilize system resources more efficiently than VM-based containers. By their very nature, containers have all the resources they need to run, including their own filesystems and network stacks, which allows many more containers to be run on the same infrastructure than virtual machines.

The efficient use of memory, processing, and networking resources has convinced some in the industry that bare metal containers are the way to go. Not to mention, if your company pays for a premium hypervisor, then running containers on bare metal servers could cut your deployment costs considerably. If your number one concern is making the most of your infrastructure, then this would be the solution you want.

Potential Concerns

The major concerns with running containers on bare metal servers have to do with security, but that isn’t the only issue. The security arguments boil down to the lack of true isolation.

Since containers make use of the operating system kernel, and in most cases, the same libraries, they could potentially represent a better opportunity for an attacker if the container could be compromised. Lack of isolation may also allow different containers to monopolize the resources of the host, interfering with other containers running on the same platform.

The last major problem relates to the sacrifice of portability; since the container does make use of the kernel of the host, there could be issues when trying to port them between different platforms. If your company has complex security concerns, is subject to stringent governance, or wants to preserve the ability to evolve your infrastructure without having to redevelop your containers, you might want to steer clear of using containers on bare metal servers.

 

Redefine your cloud data protection with automated, scalable recovery.
Watch the webinar to learn more

Can Containers Run on Virtual Machines?

The optimal deployment may be a combination of the two technologies. Deploying a container inside a virtual machine will satisfy the most dedicated isolation purist, while improving the portability of the container, since virtual machines can be moved between different platforms in a way containers on a bare metal server can’t be.

Bare metal containers lack the scalability and elasticity that’s driving most companies toward cloud solutions. Deploying the container inside a virtual machine could deliver these benefits while preserving the performance benefits expected from utilizing containers.

The Future of Containers or Containers of the Future?

It’s already apparent that containers are not only here to stay; they’re definitely going to gain popularity. If a company decides to deploy containers inside virtual machines, it can move toward a true hybrid cloud environment, freeing it from being bound to a single cloud platform and allowing entire workloads to be shifted seamlessly as necessary.

Although containers have traditionally been used for stateless applications, utilizing containers inside of virtual machines can solve the difficult problems of how to connect containers to the storage needed to maintain session data for stateful applications.

There is also a move toward creating system containers. Whether for applications or operating systems, the container is an isolated environment that can be created and destroyed as needed, and as such, it is driving a new movement toward serverless computing where apps are spun up and taken down according to demand, allowing companies to react automatically to rapid unpredictable spikes in demand while reducing cost by only paying for the resources used during the short time that the container exists.

What Not to Forget

If you do decide to go the hybrid route, here are five things to keep in mind when deploying containers inside of virtual machines:

1. Secure the guest operating system: make sure you remove any noncritical services, patch the operating system, and run vulnerability scans.
2. Choose your container base image with care: while developers may build the container from scratch, it’s common practice to download container images. It would be best to establish policies that identify secure and approved sources for container images and libraries.
3. Group containers with similar security needs: this allows you to secure the virtual machine hosting the containers to ensure compliance at a consistent level and avoid a situation where a low-security container ends up sharing a virtual machine with a high-security container.
4. Don’t save stateful data in an insecure container: containers are ephemeral and can easily be destroyed or replaced, which could result in any data inside the container being lost. To allow the data to exist when the container ends, the storage must be managed outside of the container and should be stored in a volume.
5. Provide for data protection and disaster recovery: containers are not exempt from the planning associated with these concerns. Using containers makes it easier to migrate, back up, and maintain, but you still need to make sure that they’re not exposed to metadata and configuration loss. Consider using a cloud native backup solution that will allow you to restore your entire workload to a specific point in time.

Unless your focus is solely on the efficient use of infrastructure, deploying containers inside of virtual machines might be the best way to go. While the virtual machine adds back in some of the resource overhead, the advantages of better security, portability, better scalability and elasticity, more easily managing stateful data, and metering resource usage may outweigh any potential performance sacrifices.