HP had a product announcement last month and it's one that I think was pretty exciting.  BladeSystem Matrix is a new offering from HP that pulls together compute, storage, networking integrated with a co-designed management, automation, and orchestration software stack.  From dramatically simplified ordering  to installation on the order of minutes, every aspect of delivery has been aligned with the goal of allowing customers to purchase solution ready infrastructure instead of piece parts.

In looking at the combination of software and hardware that HP has pulled together to create BladeSystem Matrix, I was struck by some familar problems of providing an agile infrastructure.   I look at BladeSystem Matrix and see many of the features and capabilties that HP has been delivering in our HP-UX, OpenVMS, and NonStop environments for a long time.   But those environments were created in an era of highly vertically integrated vendors, and the world has more options that that today.  To my mind, this exposes a tension between how we've done things and how we might see them evolve.

How thick is your OS?

When I look at the co-designed software stack of BladeSystem Matrix, I see functions for security, resource management, virtualization, availability and workload flow control.  In the OSes running on the hardware I see all those same functions along with libraries and APIs.  In fact, if I look at what's becoming one of the most important workloads running under that OS, a hypervisor, I'm seeing many of those same functions replicated yet again.  At this point, there's an 'embarrasment of riches' argument, that all those cycles replicating functions would have been wasted anyways, so why not use some of them to allow you to get a fraction more efficient?

Now don't get me wrong. A ubiquitos API and a rich library of routines is critical to making sure that we have a steady stream of software developers who can ramp quickly and stay productive for a long career. That's not going to change and there are some great examples of "the next big thing" that failed to live up to expectations because they didn't  allow a world's worth of mortal programmers to stay productive. 

But what about those other functions?  It's not just a problem of replication, it's also a problem of lack of perspective. Should we expect an OS inside of a virtual machine inside of a blade inside of an enclosure inside of a rack inside of a data center inside of an enterprise to make the right power versus performance tradeoffs?  The same OSes that we used to expect to discover and manage a whole system are now being utilized unchanged to manage a small part of a much bigger whole and that causes problems.

What this has me wondering about is the potential to offer substantially thinned out versions of today's operating systems where we retain the APIs and libraries that allow programmers to remain productive and seperate those from the resource management.  There are existing examples here from the world of high performance technical computing with thinned Linux distros, but in this case we'd need to replicate the same levels of reliability and availability as traditional OS models. 

It could be that as we continue to innovate at the intelligent infrastructure level that for the OS of the future, thin is in.