Bare metal vs virtual machines vs containers: Which is the right infrastructure for me?

There are three main infrastructure types to consider when hosting and deploying applications: Bare Metal, Virtual Machines (VMs), and Containers, each with its own advantages and disadvantages depending on your use case.

The three technologies are not mutually exclusive however, as both VMs and containers run on top of bare metal servers, while containers can also be deployed inside VMs. 

All servers used to be bare metal

Prior to innovations around virtualisation (as we understand it today) in the 1990s and the subsequent adoption of cloud technologies post 2000, all servers were bare metal. 

Bare metal essentially refers to the server hardware - a metal box containing a motherboard, processor, memory, power supply, fans, disk drives, and several other cards supporting networking connectivity ports and physical interfaces, on which software and applications would be installed. 

This physical computer would be dedicated to a single tenant, who would have complete control over all the hardware - such as type of processor, amount of memory, or size of hard drive - and the corresponding software they choose to run on it.  

Virtualisation fundamentals 

While bare metal refers to the server hardware, Virtual Machines and containers are both virtualised technologies that run in the software layer, and multiple VMs or containers can run on a single bare metal server. 

Virtualisation technology has evolved in leaps and bounds over the last 20 years, creating layers of abstraction that turn one-time hardware functions, from servers and routers to firewalls and network ports, into software, enabling the ‘as-a-service’ delivery model. 

With virtual resources isolated from the underlying hardware, they can be managed in such a way that a single physical machine can be partitioned into dozens of smaller, virtual ‘machines’.

Bare metal

A bare metal server is typically dedicated to a single tenant. The machine is built to specific requirements to support the application(s) it will be hosting, and available resources such compute, processor power, or storage would be dedicated to these applications. This means great performance for specific use cases, but if an organisation needs to run another application that requires a different operating system for example, you would need a whole different server build. 

The obvious benefits of bare metal are:

• A fully customisable hardware and software stack.
• Highest available performance with no latency caused by multiple layers of software abstraction.
• High levels of security because the machine is not shared, and potentially beneficial compliance implications. 
• Easier management - in some capacity - as a single box will have a single purpose. But this can also work against you, see below. 

Bare metal servers also have several disadvantages however:

• Dedicated hardware/software builds are more expensive, and tend not to maximise utilisation of resources. For example, an app may only use 40% of the server’s compute power on average, leaving an excess of 60%. In the case of virtual servers that excess compute could be used by other VMs.
• Scalability - in order to scale an application you need to add another identical physical server, which can be a slow and expensive process.
• Resilience - in the event of a hardware failure, such as a bad power supply or disk drive, the entire machine is out of action until repaired or replaced by an identical machine.
• Management - single tenant control means you’re responsible for the entire hardware and software stack (versus just being responsible for the software in a virtual cloud environment). The fact that servers have dedicated purposes can also add to the complexity.  

Virtual Machine

A Virtual Machine or VM is an emulation of a physical computer that runs in software through the process of virtualisation. 

Through layers of software abstraction, multiple VMs can run on one physical computer, each with their own specific operating system (OS). Management of these VMs is performed by a software known as a hypervisor, which can run on the host operating system, or in some cases on the bare metal itself. This allows multiple OSes to run on one physical machine. The VM OS is known as a ‘guest operating system’, whereas the bare metal machine uses the host operating system. 

VMs are what you would typically expect in a cloud environment, where a service provider can maximise the utilisation of physical resources by splitting them between multiple tenants and still being able to offer a mix of guest operating systems. Many cloud providers also allow customers to customise their VMs as if they were picking from a range of hardware components, such as number of virtual processors or memory.  

The main benefits of VMs are:

• Price - because the owner of the hardware is able to maximise utilisation of resources and offer multiple VMs within a single physical machine, cost efficiencies can be passed on to the end user.
• Scalability - because they are executed in software, VMs can be spun up very quickly, so adding additional compute to your application can be a simple task of adding one or more additional VMs.
• Resilience - the capabilities of virtualisation means VMs can be moved from one bare metal host to another without any downtime, so in the event of a hardware failure on the host machine, the VMs would be mirrored to another host instantly.
• Flexibility - because end users can configure VMs to their needs, you have a wider range of builds at your disposal. If you have an app with specific performance demands you can spin up VMs for that purpose and have a range of more generic VMs available for less intensive applications. 

There are downsides to VMs however:

• Security - because several tenants could be sharing the same physical server, a vulnerability affecting one tenant could also affect the others. The shared responsibility model introduced by cloud computing means the cloud service provider is responsible for the physical security and a degree of software security, with the rest being up to the end users. This makes a certain level of trust incumbent on your neighbours to not introduce any vulnerabilities that could put the rest of the tenants at risk.
  • There are some security benefits however in that applications can be isolated to specific VMs, versus multiple apps running on the same bare metal server.
• Performance - as well as a level of latency introduced by the layers of software abstraction, you may find that you’re sharing a host machine with another tenant that turns out to be a resource hog. Because all of the VMs are making use of the same host’s physical capabilities such as processor and memory, an application making a significant draw on these resources takes away from what’s available for everyone else. This is sometimes referred to as a ‘noisy neighbour’.
• Resource utilisation - although a VM is a virtualisation of the entire machine, it still operates within pre-defined boundaries. So, an overloaded VM cannot hand off processing demand to the host processor, instead you would need to add an additional VM, or deploy a VM with a more appropriate configuration. 
  
  

Containers

Containers are considered the most lightweight of the virtualised offerings, these are small self-contained packages that contain an application along with all its dependencies, such as libraries, frameworks, and runtime, and make use of the features and resources of the host OS. 

Unlike VMs, where the hardware is virtualised and managed through a hypervisor, a container engine, such as Docker, virtualises the operating system itself and enables multiple containers to run, each with its own isolated application environment.

Containers offer several benefits:

• Portability - containers are lightweight and fast making them very flexible and portable. A containerised application could run on a private cloud today and as the organisation migrates to the public cloud, the containerised app can be moved to a new infrastructure without much trouble. Migrations from one cloud to another, such as AWS to Azure, are also possible.
• Price - because containers make even better use of resources than VMs they are the most cost-effective option for applications that need to run on a limited number of resources.
• Performance - for apps that need limited resources, containers offer a level of isolation that prevents conflicts with other apps and their dependencies. But this makes them limited in scope as we see below.
  
  

Of course, containers have several disadvantages:

• Security - As containers on a host all share the same operating system kernel, any vulnerabilities that give access to one container may make other containers on the same host vulnerable as well. This can also raise compliance concerns for companies in certain industries.
• Functionality - Containers largely rely on the capabilities and features of the host OS and only have access to limited libraries and dependencies, making them very efficient but somewhat limited in scope.
• Management - Slicing up physical machines into dozens or hundreds of containers results in lots of moving parts that need to be managed and creates a very complex environment. By its nature this introduces a higher chance of misconfigurations and vulnerabilities. 
  
  

Containers inside VMs and containers on bare metal

It is possible to get the best of multiple worlds, by deploying containers on VMs or bare metal, although one setup is more common than the other. 

When using VMs as container hosts, the containers can take advantage of the hypervisor for high availability and resource scheduling as well as benefit from better security by reducing the possible attack surfaces. However, this comes at a performance and flexibility cost as you are increasing the layers of software abstraction and offsetting the benefits of portability with the restrictions of the VM. 

Running containers on bare metal is also a possibility but would more likely be seen in on-premise environments than the public cloud. Most public cloud providers do not even offer such capabilities, AWS and Rackspace are two that do. 

Although you could gain performance benefits, containers on bare metal are reliant on specific hardware and software configurations and upgrading physical machines is more complex as you need to recreate the container environment from scratch. 

VM environments also offer the ability to take snapshots and roll back environments to a specific point in time, something not possible with containers. 

In short, for high performance with a high budget, bare metal may be the way to go, but for flexibility and scalability, VMs are likely the answer. If rapid deployment and portability are your prime concerns, containers could be the solution you’re looking for. 

At the end of the day, most companies will have multiple use cases and may well end up with a mixture of two or three deployment models.