In 2016, Kelsey Hightower’s “Kubernetes the Hard Way” highlighted the specialized skills needed to operate complex and powerful platforms. Fear of that complexity and a lack of advanced operations knowledge has kept enterprises from using Kubernetes to get the full value out of their bare metal infrastructure that Google had achieved with Borg, their internal project that inspired Kubernetes.

That ops limitation has stood for over a decade, but we’re seeing a new appetite for bare metal.

Roadmaps have significantly shifted in enterprise thinking since Broadcom’s acquisition of VMware. Infrastructure leaders are questioning the wisdom of staying with VMware, and virtualization more generally, as their foundational infrastructure abstraction. Even beyond cost, the overuse of virtualization as the core infrastructure abstraction limits innovation.

Among our customers, CIOs are asking if Kubernetes can become a common platform beyond AppDev use-cases also to solve infrastructure challenges in virtualization and AI. They want to know if cloud-native architecture, and by extension Kubernetes, creates strategic alignment that allows enterprises to move faster, scale more easily, create more choice, and navigate with confidence in a changing landscape?

But first … drop the performance red herring

Let’s dispense with the bare metal versus virtual machine (VM) performance discussion. If you are using Kubernetes clusters for managing applications in containers, then you should do it in VMs. The marginal performance hit of virtualization does not outweigh the significant management streamlining. If you are considering bare metal, then it should be because you have a use case that interacts with physical infrastructure like running VMs or AI workloads.

This generalization applies because dealing with the networking, storage, configuration, and lifecycle upkeep of bare metal adds complexity that is not needed for simple container management.

Different use cases on a common platform

The distinction between virtualizable and physical workloads is a critical distinction: Kubernetes application and infrastructure use cases are so fundamentally different that they should be considered different skill sets. Enterprises do get a benefit from having a common platform for training, tooling, and licensing, but should not expect expertise in different use cases to translate. Understanding the platform engineering to support a dynamic application and development team does not match to the more static and performance focused needs for a virtualization support team or the performance networking and firmware needs of an AI cluster.

I’ve watched leaders stumble here: assuming their application platform teams will simply extend into infrastructure operations has been a recipe for significant delays, restarts, and operations confusion. Accepting that different use cases require different expertise helps us get the most from Kubernetes as a common platform. The recognition makes it possible for leaders to both focus their expertise and collaborate more easily.

From common platform to consistent processes

But if the use cases and skills are so different, why is having a common platform strategic? It’s critical to remember that IT strategy is more about processes than platforms. There are two major benefits in bringing to Kubernetes to bare metal as a common platform.

The first is bringing API-driven, infrastructure-as-code (IaC) and cloud-native thinking to our foundational infrastructure layer. Enterprises have been locked into a static 2010-era virtualization architecture that limits process improvements and integration in the stack.

The second is getting the benefit of common tooling and shared knowledge. Even though the use case still requires specialized skills, enterprises benefit when teams are able to collaborate and consolidate platforms.

I need to repeat that developers and SREs should not be running infrastructure; instead, leverage their experience as advisors and process guides. Even more critical is investing in proven and scalable processes will benefit everyone. Ultimately, the knowledge and process transfer will be multidirectional.

Missing skills and practices: the operations gap

If Kubernetes managed infrastructure is not a developer project, how can enterprise operations teams build their experience?

In 2017, when I started advocating for bare metal Kubernetes as the Ops SIG chair, I asked one of Kubernetes’ founders, Joe Beda, what he’d learned from Google’s experience that could help. Beda described that Borg platforms rested on an even more foundational layer that handled low-level functions like conditioning hardware, providing lifecycle management, and providing an API abstraction. While AppDev users get that from cloud abstraction, virtual and AI users still need an underlying abstraction.

The problem for many enterprises is that their current platforms and processes will not measure up. They are too manual, slow, or unreliable. Worse, “API-ifying” your current infrastructure loosely connected automation tools while trying to learn cloud-native operations may further slow your operations teams at the exact time you need them to accelerate into a new architecture.

In my experience, teams overestimate the risk-versus-benefit calculation of bare metal automation changes. Modern platforms are API-driven and support cloud-native, immutable processes. Even better, they have significant out-of-the-box capabilities and IaC delivery, making them fast to deploy and safe to scale.

Most critically, operations teams can leverage proven practices to come up to speed on Kubernetes quickly. These platforms don’t replace Kubernetes, they provide the bare metal abstractions so that it can manage it effectively with the operational visibility and control.

The bottom line

Bare metal Kubernetes represents a strategic path to a common platform for AppDev, virtualization, and AI use cases. Successfully embracing this strategy means recognizing that these use cases are still unique operational areas so help teams build and share cloud-native processes that fit their specific needs.

To accelerate that transition, revisit the risk-benefit assumptions that prevent you from reinventing your underlaying bare metal systems. After all, this is a one-in-a-generation opportunity to improve and align your infrastructure delivery.

Ready to test these assumptions? Start with a single bare metal cluster pilot for your next AI or virtualization workload. Prove the operational model before betting the infrastructure strategy. Your future CIO will thank you.