Even in today’s cloud-first environment, bare metal workloads play a significant role in the data center. It’s true that legacy hardware drives the requirement to keep bare metal workloads running in the data center. The likes of ERP and vertical-specific software means that bare metal workloads will exist in the data center for the foreseeable future.

Legacy use cases aren’t a provisioning challenge. These applications tend to remain very static in capacity and configuration. A real challenge is cloud-native applications that take advantage of the elastic nature of abstracted infrastructure. With application developer projects such as Kubernetes or infrastructure focused platforms such as OpenStack, an abstraction exists between the physical underlay and the end user.

However, at the end of a request for a function in a serverless environment, or a call for an OS instance, physical infrastructure is provisioned. There are cases where deploying a hypervisor adds limited value. Examples include analytics applications and in-memory databases. Heavy duty analytics applications may consume all the available CPU resources of a host. Similarly, a Spark instance may consume all of the available physical CPU and memory of a physical host. High performance computing (HPC) is another example of the need for bare metal servers in a data center.

Software-defined infrastructure

I attended a software-defined infrastructure (SDI) event at Intel about a year ago. One of the themes of the event was driving data center efficiency. Intel found that, before undergoing an SDI transformation, server efficiency was less than 50%. Even inside a company where physical infrastructure costs are relatively low, the cost of low utilization is impactful to the bottom line.

It’s no longer enough to over provision underlying infrastructure and leave resources idle. Layering a hypervisor on top of performance workloads increases agility, but at the cost of a slight performance hit. Organizations looking to drive efficiency are forced to look into bare metal server orchestration.

Physical server orchestration isn’t a new concept. Every major server vendor has pushed an orchestration platform at some point. Dell, Cisco, Lenovo, and HPE all have solutions that allow customers to provision servers using tools designed for their platforms. The challenge is developing strategy independent of a specific vendor’s platform.

Even within a particular vendor, there are challenges. HPE, for example, announced their Synergy platform. Synergy allows for orchestration of configuring blades to run varying workloads. HPE calls this capability composable infrastructure. However, Synergy is limited to a subset of HPE’s product offering. The ability to compose infrastructure from competing solutions is far off. Similar challenges exist within other products.

Orchestrator of orchestrators

Given the limitations of each vendor approach to automation, customers have two options as I see it. The first is to take an orchestrator of orchestrators approach. Using a base orchestration platform, such as VMware vRealize or OpenStack, customers can use the automation mechanisms available in each solution to make calls to vendor-specific tools.

See: How storage startup Rubrik models DevOps

Using this approach, customers build the automation logic within the base orchestration platforms. The centralized approach allows data center scheduling solutions such as Kubernetes to make calls to vRealize or OpenStack, which then kicks off automation in Cisco UCS, for example. The base orchestration platform abstracts all of the tools underneath.

The second approach is to leverage open source tools such as Puppet and Chef. Using these tools in place of OpenStack or vRealize, engineers create scripts that either call vendor-specific tools, or perform the actions directly on the hardware platform.

The details

I don’t want to leave the reader with an impression that this is all natural stuff. Automation, in general, is hard. Integration of different automation solutions and platforms is even more challenging. Don’t attempt to boil the ocean when approaching bare metal server automation.

I’d suggest starting with low hanging fruit. Take a look at the workloads you build most often. If it’s VMware vSphere hosts, then understand what is required to automate the server build from unboxing to joining a VM cluster. The automation should include RAID configuration, BIOS settings, and firmware checks. The goal is to unbox a server, place it in a rack, and power it on.

At the end of this process, you’ll have an appreciation for the level of difficulty this brings, but you’ll also have a great foundation for building a software-defined data center that takes bare metal servers into account.