The Ideal of Composable Infrastructure

With the release of Synergy (see my recent post), HPE is moving towards a future that sees IT resources aggregated into applications deployed on-demand and in a totally automated fashion. In reality though, has HPE reached that stage with Synergy and can we put a definition on what Composable IT really means?

If we look back at IT history, then IBM’s System/360 (onwards) architecture is probably the best definition of what constitutes a composable solution. Compute was one large monolithic unit, as was networking (which ran in software). Storage was delivered physically through volumes but accessed by a hierarchical catalog (so the data could reside anywhere). Work was run as batch jobs (short lived containers), started tasks (long running containers), or user login time sharing (VDI). The mainframe was successful because IBM owned all the parts (including software) and set the standards. You didn’t need to know where your application ran, just that it needed a certain amount of compute time and would create/destroy files (which were eventually managed through SMS, that abstracted the location and service levels for each file).

Moving to the present day and as part of Synergy, HPE has divided compute into blades, or compute nodes. Networking is delivered through a VirtualConnect fabric and data is mapped to disk drives that are attached to compute as DAS (direct attached storage). Applications can run on bare metal, as VMs or as containers. All of this infrastructure can be managed through APIs, driven by features such as software defined networking and software defined storage (HPE’s words) and accessed from resource pools. However at this stage, everything still feels very hardware focused, rather than being a service orientated architecture. Storage is assigned as hard drives (or presumably flash), rather than being accessed in pools or objects. Compute is built from blades (no SMP as far as I’m aware). Synergy is more about automation than what composable really could mean.

A Definition (of sorts)

So here’s what I think needs to be included into the idea of composable IT:

A Framework – the framework defines what the individual objects “of composure” are. These may be blades, VMs or containers, VVOLs, objects in an object store, files or LUNs. Networking components would include VLANs, IP and MAC addresses. Above that there are the environmental components – operating systems or container hosts. These define the operating architecture for the application (e.g. x86, Windows, x86 Linux) rather than the specific version/release (although that still has to be there in some form). Taking storage as an example, each object needs to have service levels assigned, including (for example) Quality of Service, data protection, resiliency. In this way we abstract more from the hardware, while having to maintain the legacy of our IT history.
Policy – a set of rules that determine how components can be combined. Policies would exist on multiple levels; there’s the group of policies put in place to ensure that resiliency is built into the architecture (don’t build RAID from disks on the same shelf, for example) and to ensure that applications receive the performance/availability needs they require. Then there are policies that create applications, what might also be termed templates. Within those templates, specific policies would also cover application requirements like compliance, data protection, availability and dependencies.
Analytics – with a truly fluid environment, applications will be transient and the workload mix will constantly change. This needs a feedback loop to continually monitor the infrastructure and make decisions about where new applications should be deployed. Without this, the environment will have to be managed in the traditional way, which is ultimately not scalable. The feedback loop is also necessary to ensure that new resources can be added and consumed with automatic rebalancing if appropriate.

There’s a philosophical question to be asked as to how far the idea of composable should break objects down. Should (for instance) an object store be built from software and DAS, or installed as an appliance? Should block-based storage be delivered through an appliance (like 3PAR) or purely through software (such as StoreVirtual and DAS)? Unfortunately we’re in a place that still means we’re dealing with legacy architecture (just think how we are using virtual machines as a representation of our previous physical infrastructure, rather than moving to abstracted applications in containers). Because of this we would be crazy to throw away years of invested intellectual property just to maintain a degree of purity in design. Instead we should look to solutions that can be driven (managed and monitored) through APIs and work with abstract concepts (like QoS already mentioned).

The People

As IT organisations have scaled, the generalists have become specialists in storage, networking, compute and applications. This was necessary as those disciplines mapped to our infrastructure. Going forward we have a much more complex scenario to manage. Composable means working with an entirely holistic computing environment where the consequences of one change could have ramifications across the entire infrastructure. We will need a new breed of “super architects” who can work both at the 30,000 feet level and in detail, in order to understand the implications of policy, template and ultimately application design.

The Architect’s View®

I love the idea of being able to break down the barriers of delivering applications by automating as much as possible in the infrastructure. Abstracting the hardware into logical objects that can be combined into an application is that next evolution in making us faster and more agile than ever before. We’re only at Composable 1.0 today; let’s see where 5 years of development gets us. I think by then the IT world will be a very different place.

Do you think HPE have delivered? What’s your opinion on Composable IT – the future or just another buzzterm?

A Definition (of sorts)

The People

The Architect’s View®

Further Reading