Hi. Welcome to another system design video. What are the differences between bare metal, virtual machines, and containers?
When deploying a modern application stack, how do we decide which one to use? In this video, we’ll take a closer look at each of these. Let’s dive right in.
The granddaddy of these is bare metal. A bare metal server is a physical computer that is a single tenant only. Once upon a time, all servers were bare metal.
Bare metal gives us complete control over the hardware resources and the software stack to run. For software applications that require the absolute highest performance from the hardware, bare metal could be a good way to go. Bare metal servers are physically isolated.
The isolation provides two benefits: First, it is not affected by the noisy neighbor problem. This problem occurs when one tenant's performance is impacted because of the activities of another tenant sharing the same hardware. Second, the isolation provides the highest level of security.
For example, it is not affected by side-channel attacks. These attacks take advantage of the design flaws in modern microprocessors to allow a malicious tenant to steal secrets from its neighbors. This strong security guarantee is another reason to use bare metal.
When an application needs to meet the most stringent security, compliance, or regulatory requirements, bare metal could sometimes be the only way to go. What are the downsides of bare metal? Bare metal is expensive, hard to manage, and hard to scale.
Acquiring new hardware takes time, and it takes a competent team to manage them well. Next up is Virtual Machines. A virtual machine is the emulation of a physical computer.
This is called virtualization. Many virtual machines can run on a single piece of bare metal hardware. On top of the bare metal hardware is the host operating system.
Running on top of the host operating system is a special piece of software called a hypervisor. This is also known as a virtual machine monitor. The hypervisor manages virtual machines.
It creates an abstraction layer over the hardware so that multiple operating systems can run alongside each other. Each virtual machine has its own guest operating system. On top of each guest operating system runs the applications for a tenant.
As a side note: There is a concept called bare metal hypervisor, not to be confused with bare metal hardware. A bare metal hypervisor controls the hardware directly without relying on the host operating system. This gives the hypervisor full control over the hardware and provides higher performance.
However, hardware that supports the bare metal hypervisor is more expensive. Virtual machines have come a long way in performance and scale. These days we can choose virtual machines of pretty much any size to fit our workloads, from general purpose ones with just a few cpu cores and a few GBs of memory, to high-performance ones with hundreds of cores and terabytes of memory.
What are the benefits of virtual machines? Virtual machines are cheaper to run. Many of them can share the same hardware, allowing much higher resource utilization.
They are easier to scale, too. This provides an organization more flexibility. Scaling up virtual machines is easier.
Some fancy virtualization software can even move a running virtual machine from one bare metal hardware to another without shutting down the virtual machine. What are some of the downsides to virtual machines? Virtual machines could be vulnerable to the noisy neighbor problem described earlier.
If our application co-locates with a resource hog of a neighbor, our own application performance could suffer. Also, virtual machines running on the same bare metal hardware share the same physical CPU cores. They are vulnerable to attacks that aim at design flaws in modern processors.
Side-channel attacks like Meltdown and Spectre are some well-known examples. Next up - Containers. A container is a lightweight and standalone package of an application with all its dependencies like libraries, frameworks, and runtime.
Containerization is considered to be a lightweight version of virtualization. Like virtualization, here we have bare metal hardware and the host operating system. But instead of virtualizing the hardware with a hypervisor, we virtualize the operating system itself with a piece of special software called the container engine.
On top of the container engine runs many containers. Each of these is its own application environment isolated from each other. The container engine provides even faster resource provisioning.
And all the resources needed to run the application are packaged together, so that the applications can run anywhere. Containers are scalable and portable. They are lightweight and require less hardware resources to run than virtual machines.
A bare metal server can host significantly more containers than virtual machines. Since each container runs as a native process of the host operating system, they are much faster to start, too. All these make containers even easier to deploy and maintain at scale.
However, containers are potentially less secure. They share the same underlying operating system, and the isolation relies on the OS-level primitives. This means containers are exposed to a wider class of security vulnerabilities at the operating system level.
It is possible to run containers inside virtual machines. Why would we want to do that? One reason is that it provides better security by reducing the possible attack surfaces.
This is a tradeoff between flexibility and security. What comes after containers? Serverless and edge computing come to mind.
They make the developer productivity and deployment stories even more compelling, but with their own sets of tradeoffs. We might look into these in another video. In conclusion, system design is about tradeoffs.
It is no different when it comes to bare metal, virtual machines, and containers. There is no single right answer. If you would like to learn more about system design, check out our books and weekly newsletter.
Please subscribe if you learned something new. Thank you so much, and we’ll see you next time.
