Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Where to run containers: Bare-metal servers vs. virtual machines

By running Docker containers on bare-metal servers, organizations get portability and stability. Expert Christopher Tozzi explains why, sometimes, virtual machines may be a better choice.

You know why you should consider using containers. But do you know which type of infrastructure to deploy them...

on? Are bare-metal servers better than virtual machines as hosting platforms for Docker and other container environments?

The answer, of course, depends on lots of variables. This article discusses them by explaining the pros and cons of running containers on bare-metal hosts, as well as virtual servers. I'll focus on Docker, but the lessons here apply generally to any type of container platform.

Bare metal vs. virtual machines

Weighing the respective advantages and disadvantages of bare-metal servers and virtualized hosting environments is not a new issue. It has been on CTOs' minds since virtualization became widespread in data centers in the 2000s, long before anyone had heard of Docker.

Briefly, the main benefits of bare-metal servers include:

  • Higher performance, because no system resources are wasted on hardware emulation;
  • Full use of all machine resources, as none of them sit idle during high-demand periods; and
  • Easier administration, because there are fewer hosts, networks and disks to contend within the infrastructure.

Virtual machines, meanwhile, offer the following advantages:

  • The ability to move applications easily between hosts by transferring virtual machine images from one server to another;
  • Isolation among applications that run inside different virtual machines. This provides some security benefits and can reduce management complexity; and
  • The ability to maintain a consistent software environment across your infrastructure by deploying all apps on a same type of virtual machine, even if the underlying host servers are not homogenous.

But virtual machines also come with some drawbacks. They include:

  • Server resources may not be fully used. For example, if you allocate storage space on a server host in order to create a virtual machine disk image, then that storage space becomes unavailable for other purposes -- even if the virtual machine to which the disk is attached does not use the whole space.
  • Virtual machines can't access physical hardware directly. For instance, if you want your virtual machine to be able to offload compute operations to a GPU on its host, you can't do that -- at least not easily -- because a virtual machine is abstracted from an underlying host environment.
  • Virtual machines generally don't perform as well as physical servers because resources are consumed emulating hardware for a virtual server.

Modern virtualization platforms provide some tricks that can help admins work around the limitations mentioned above. For example, you can create a dynamic disk image, which expands as its usage by a virtual machine increases to avoid locking up storage space on a host before it is actually used by a guest. You can also leverage pass-through features to provide virtual machines direct access to physical hardware on a host in some cases.

However, these hacks don't always work well. They are not supported on all types of hosts and guest operating systems, and they create additional administrative burden. If the apps you want to run require a bare-metal access, then it's best to run those apps on a bare-metal server.

Or, you could run your apps inside containers on a bare-metal server, in order to get the best of both worlds.

Squaring the circle: Running containers on bare metal

Containers on a bare metal provide many advantages of virtual machines, but without the drawbacks of virtualization. When you run containers on a bare-metal server, containers allow you to:

  • Access bare-metal hardware in your apps without relying on pass-through techniques, because the app processes run on the same operating system as the one that powers a host server.
  • Make optimal use of system resources. Although you can set limits on how many compute, storage and networking resources containers can use, containers generally don't require these resources to be dedicated solely to a single container. A host can, therefore, distribute system resources as needed.
  • Get bare-metal performance to your apps, because there is no hardware emulation layer separating them from a host server.

In addition, by using a bare-metal container host, you still get the following benefits that have traditionally been possible only if you use virtual machines:

  • The ability to deploy apps inside portable environments that can move easily between host servers.
  • App isolation. Although containers arguably don't provide the same level of isolation as virtual machines, containers do allow admins to prevent apps from interacting with one another and to set strict limits on the privileges and resource accessibility associated with each container.

In short, containers running on a bare metal allow you to square the circle. You get all the benefits of bare-metal performance and hardware access, as well as the portability and isolation features of virtual machines.

Why you should not always host containers on bare metal

You probably are wondering why you would ever not run your containers on bare metal. If that approach gives you the best of both worlds, why would you ever do otherwise?

Consider the following drawbacks of using bare-metal servers to host your container engine, rather than virtual machines:

  • Upgrading physical servers is difficult. If you want to replace your bare-metal server with a newer one, you'll have to re-create the container environment from scratch on a new server. If the container environment were part of a virtual machine image, however, you could simply move the image from an old to a new server.
  • Most clouds require you to use virtual machines. There are some bare-metal cloud hosts out there, like Rackspace's OnMetal offering and Oracle's Bare Metal Cloud Service. By and large, however, most public cloud providers only offer virtual machines. If you want to use their platforms for running your containers, you'll have to use virtual machines.
  • Container platforms don't support all hardware and software configurations. These days, you can host almost any type of operating system you want using a virtual machine platform like VMware or kernel-based virtual machine. And you can run that virtualization platform on almost any kind of operating system or server. But Docker is more limited. It can run only on Linux and certain Windows servers if it is hosted on bare metal. It implies that if your bare-metal servers run, say, Windows Server 2012 -- which Docker does not currently support -- and you want to host Docker on them, you'll need to install a virtual machine on top of the Windows host in order to accommodate Docker.
  • You can't run Linux containers on a Windows host, and vice versa. Related to the above drawback is the fact Linux containers can only run on a Linux host, and vice versa. So, if you have a bare-metal Windows server, but you want to run a Docker container on it to host an app compiled for Linux, you'll have to install a Linux virtual machine on the Windows server and use that as the environment for hosting Docker.
  • Bare-metal servers don't offer rollback features. One cool feature that is available in most modern virtualization platforms is the ability to take a snapshot of a virtual machine and then roll back to that snapshot at a later time, if desired. You can't do that with a bare-metal server. (Well, you technically might be able to use rollback features built into your operating system or file system, but those are not nearly as seamless as rolling back a virtual machine image.) And the idea of snapshots and rollbacks on containers doesn't really make sense. Containers are ephemeral by nature, so there is nothing to roll back to. As a result, the only way to take advantage of simple system rollback is to host your containers on a virtual machine.

Conclusion

It is a tough decision to make, whether to run containers on bare-metal servers or on virtual servers. You'll have to weigh various pros and cons to determine which approach will work best for your organization.

The good news is no matter where you host your containers, you'll still benefit from all of the core features of containerization, including simple app portability, scalability and agility.

Next Steps

Companies are driving toward bare-metal deployment methods

Learn more about bare-metal virtualization hypervisor

Learn about the storage options in VM-aware

This was last published in November 2016

Dig Deeper on Cloud application development and deployment

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Which is your pick for containers: VMs or bare-metal servers?
Cancel
Could you not use Kubernetes as an orchestration layer on top of bare-metal to offset some of the drawbacks? Also, this doesn't have a published date, but with Windows 2016 you can get a Linux container to run on Windows. https://forums.docker.com/t/linux-container-in-w2k16/26321/5
Cancel

-ADS BY GOOGLE

SearchAWS

TheServerSide.com

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

SearchSalesforce

DevOpsAgenda

Close