If you follow tech media coverage of the service provider space, you’ll occasionally come across some eyebrow-raising claims. One that stands out recently: cloud-native software vendors introducing something called “bare-metal cloud.” “Wait,” you might ask, “aren’t the concepts of cloud and bare-metal mutually exclusive? If you’re deploying software directly on physical servers, with no virtualization layer, don’t you lose most of the flexibility, automation, and resource efficiency that comes with modern cloud environments?” Yes, yes you do.
If you’re running a large-scale telecommunications network, there may be justifiable reasons to use bare-metal approaches in certain circumstances. And there are a million good reasons to run parts of your network more like a cloud data center. But for any given workload, you do have to choose. You can’t go bare metal and still get the agility and flexibility you expect from the cloud.
What, exactly, are vendors trying to sell you with this bare-metal cloud concept? And what parts of the story are they omitting when they do? Let’s take a closer look.
Pulling Back the Curtain
Before we evaluate claims, let’s define terms. “Bare metal” is simply another way of saying “physical server.” More specifically, bare metal implies servers without a hypervisor—i.e., without virtualization. What about “virtualization?” Fundamentally, it means inserting an abstraction layer (the hypervisor) between hardware and applications, so you can run multiple workloads and operating systems on the same physical server.
Now, here’s where things get fuzzy for vendors pitching “bare-metal cloud”—intentionally so. They’d like you to believe that all the things we love about the cloud—maximizing resource utilization, running more workloads with less power and operating expenses (OpEx), automating provisioning and scaling, and paying for only the resources you consume—have nothing to do with virtualization. But that’s simply not the case.
Almost all the benefits we expect from cloud flow from the ability to abstract away the complexities of the underlying hardware infrastructure. Without a hypervisor, you can’t do that. Worse, when you deploy on bare metal, your workloads become more dependent on the specific hardware they’re running on, making them harder to move or change or automate. You also break true consumption-based pricing since there’s no way to provision a fraction of a physical server.
Effectively, you’re back in the 1990s, when scrunchies and acid washed jeans reigned supreme and every server was dedicated to a specific application, and running a data center meant babysitting physical boxes. The whole reason we started using “cloud” was to signify an expansion of virtualization. That is, not just virtualizing compute and memory (servers), but also network and storage, so we could define a complete data center infrastructure in software and provision those virtualized resources programmatically, on demand.
Interrogating Bare Metal
When you understand what cloud actually entails, the notion of getting all the benefits of virtualization without virtualizing seems tough to reconcile. There are good reasons the industry moved to abstract away physical infrastructure 30 years ago and has been doing it ever since.
Vendors pushing bare metal point to a multitude of benefits of using a physical server approach. But if you look closely, most of those benefits don’t hold up over time:
- Performance: Some vendors argue eliminating hypervisors boosts performance. While older hypervisors did sometimes diminish performance, modern virtualization platforms don’t. VMware virtual machines (VMs) and Tanzu Kubernetes containers deliver performance on par with bare metal, even in demanding environments like radio access networks (RANs). Some vendors also claim bare metal boosts performance by giving applications direct access to a server’s processing power. But the overhead needed to run a hypervisor is negligible for high-performance applications. And you can still take advantage of hardware optimizations like single-root I/O virtualization (SR-IOV) and Data Plane Development Kit (DPDK) when applications need direct access to hardware.
- Costs: When vendors say bare-metal deployments cost less, they mean your initial capital outlay can be lower since you’re not buying virtualization software. Take note that they never mention OpEx. You still have the same lifecycle management effort for applications and OSs, so no change there. But now, you also take on the costs of powering, cooling, connecting, and maintaining much more physical hardware. Running Kubernetes on bare metal does nothing to alleviate server sprawl. The solution to that problem is the same as it’s always been: virtualization. If you’re measuring total cost of ownership over the life of your investment, running bare metal inevitably adds operating costs and complexity, while limiting your flexibility to evolve your environment over time.
- Security and compliance: Some vendors claim bare metal strengthens security by physically isolating workloads. But this is an antiquated approach to application security. Modern cloud environments use strong hardware and software protections to enable resource-sharing across shared compute, network, and storage, without compromising individual applications or tenants. Arguably, virtualization increases security, since it provides one more layer for multi-layer defenses, including VM-level micro-segmentation, firewalling, and access control. Even when compliance requirements demand dedicated physical hosts, you can still use virtualization. VMware platforms have been certified against Common Criteria security compliance for regulated environments for years.
Does Bare Metal Make Sense for 5G?
Finally, the big question: does running on bare metal make it easier to “cloudify” your network for 5G, or to capitalize on emerging open RAN (O-RAN) and virtualized RAN (vRAN) innovations? The short answer is no. Whether vendors call it a “cloud” or not, running a bare-metal architecture means the foundation of your applications—and with 5G, the foundation of many parts of the network itself—depends on rigid, inflexible hardware infrastructure.
If you’re rolling out O-RAN/vRAN to thousands of cell sites, you might be tempted to skip virtualization, but you’re taking a big risk if you do. Maybe you can run early vRAN workloads on bare metal. But what happens a year from now, when you want to add new O-RAN vendors, or beat the competition to new RAN-hosted edge applications? How will you expand capabilities when every workload needs its own dedicated server? It’s not like you can squeeze more hardware into most of those sites. How will you evolve your network, and how much will that cost?
Author: Jason James, Systems Architect and technology enthusiast, is long time designer of systems that ensure performance, resilience and reliability. In his position as the Senior Competitive Marketing Manager at VMware, he uses his over 20 years of systems engineering experience to analyze solutions in the marketplace.