Learn how composable IT works, and find out when this highly flexible, programmable infrastructure model makes sense for your servers, network, and storage and when it doesn't.
When we first started using virtualization, the value was in saving money by consolidating low-utilization physical servers. But soon after deploying virtualization, it became clear the flexibility and agility of virtual machines was even more valuable than the cost savings.
Composable infrastructure, or architecture, aims to bring that same flexibility and agility to bare-metal deployment through a controller that provides a programmable interface to assemble servers, networking and storage into a customized platform. Composable IT addresses the need to have relatively short-lived platforms with specialized configurations.
When should I compose?
Composable infrastructure suits dynamic environments where virtual machines (VMs) on an existing hypervisor cluster are not the best solution. For example, projects that run for a few weeks or months are a classic dynamic requirement where composable architecture enables a custom hardware deployment for the project from a resource pool. One project might need a kernel-based VM hypervisor, and the next might need vSphere, containers on bare metal or a combination of platforms. Composable architecture enables you to assemble the required components using software control and software-defined hardware.
What can I compose from?
Most composable architecture enables programmatic control of storage and networking -- some implementations add generic PCIe devices, too -- which is attached to compute servers. The compute is typically dual-socket servers in rack or blade form, your standard data center workhorse servers. Because Intel and Advanced Micro Devices both have memory controllers inside the CPU, it isn't possible to separate RAM and CPU into separate composable units.
Composable infrastructure suits dynamic environments where VMs on an existing hypervisor cluster are not the best solution.
The network is usually 10 GBps or faster Ethernet adapters in the servers attached to switches that are programmed by the controller. Programmable storage might consist of a SAN or a SAS fabric with a lot of drives -- the SAN for shared storage and the SAS fabric for flexible local storage in the hosts. Soon, the SAS fabric will be relegated to secondary storage, and NVMe-oF will enable faster access to pooled solid-state storage, as well as the SAN. Compute, storage and networking are pools of resources that the controller assembles into servers.
What should I compose into?
The short answer is you can compose whatever your application requires at the moment. You might have a group of servers with SAN storage built as a conventional hypervisor cluster or the same servers with a lot of SAS storage as a hyper-converged infrastructure (HCI) cluster. A different project may require servers with a small amount of SAS storage and Linux installed as a Kubernetes, SAP HANA or Oracle Database cluster, possibly with the SAN providing shared persistent storage.
There are also compelling use cases where the composable infrastructure plays different roles at different times of the day, week and month. During work hours, the servers may be an HCI cluster for a software development team, while, at night, the same servers are composed into an analytics cluster to crunch a vast amount of data. The controller may even dynamically move hosts between the HCI cluster and the analytics role based on resource demand over a single day. The controller could be your scheduler of schedulers, controlling access to pools of servers, storage and network that are then delivered to hypervisors or workload schedulers like Kubernetes.
When shouldn't I compose?
Composable infrastructure targets scale-out applications, whether physical or virtual. But it has limited ability to scale up, since you can't assemble multiple CPU-RAM units into a massive single address space.
The other reason not to use composable IT is when your environment doesn't require a lot of agility. For example, you might have a production SAP HANA environment that will run for three to five years and, therefore, has no requirement for the dynamic nature of composable. This environment is better suited to a hardware configuration optimized to the static workload. Composable architecture doesn't need to replace your virtualization platform but does enable the same flexibility for nonvirtual workloads. You may link your virtualization platform to your controller, however, to enable workloads to span virtual and physical servers.
Composable infrastructure brings the agility and flexibility of a VM to physical servers. With it, you can build customized server configurations from pools of servers, storage and networking for the current workload requirements and then reassemble those configurations when needs change.
