Is OS virtualization an end in itself? Is it both necessary and sufficient for all things Cloud and IaaS? Is it the panacea IT Operations has been looking for? From where I see it, abstracting the OS is certainly a great start, but it’s actually only 50% of the goal.

To a degree, OS virtualization is the “shiny metal object” de jure in that it’s captivating everyone’s attention. It is of course very valuable, and is causing an important inflection point in datacenter operations and economics.  But there is a less-visible, less sexy side to datacenter operations and economics that lies “below” the CPU in the stack – it’s the I/O, network, network devices and address space.  And this represents the other 50% of the transition to more agile and efficient IT.

The value of OS virtualization is in its ability to abstract the OS so that higher-level services are possible – workload consolidation, portability, migration, failover, scaling, etc.  But viewing this purely from an above-the-CPU, software-centric perspective is myopic. Lots of other things need manipulation in a production datacenter.  For example, when a server (or service) gets moved, I/O and addressing need to change; security policy (and/or devices) need to follow the application; switch/router ports may change; load balancing and other IP devices need to be reconfigured.  While OS virtualization simplifies application workload management, it certainly doesn’t address these network-centric and QoS-centric issues. 

This whole idea was neatly encapsulated recently in a blog by VMware’s Mark Thiele:  “When you can log into a console and use your mouse pointer to drag a server into a network or resource pool and have the appropriate network security and routing policies applied, you’ll be getting close to IT nirvana”

And that’s the first big takeaway for what a more dynamic infrastructure (“Infrastructure 2.0”) will bring: The same level of agility, control, security and efficiency to the network that OS virtualization brings to the workload. 

Unfortunately the networking half of the dynamic IT story is still sadly lacking in maturity… as evidenced by the many static network diagrams I see pinned to walls, and by the many manually-administered IP address and DNS spreadsheets sitting in managers’ offices. This dynamic network infrastructure is what marketers call a “Latent Want”. It’s a need that’s unfulfilled, but also largely unrecognized.

How’d we get into this mess?

The statically-defined address/naming space and networking topologies arose mostly as a function of the evolution of the CPU itself, and how datacenter networking, storage and security components evolved around it.  Briefly, server technology slowly became laden peripherals like I/O cards with static state such as addresses and WW names; once these servers were cemented in the data center, the network & its devices had to be similarly statically configured (See more about how the Industry Went Amiss).

Fortunately, there are a number of products just coming to market that are beginning to bring virtualization/abstraction to the I/O and networking world as well.  Also with the advent of unified computing concepts, virtual I/O, and converged networking, some of these tight I/O and network bonds are just now being broken. In an excellent Illuminata summary of the burgeoning abstraction of the network, Gordon Haff observes how more dynamic infrastructure is also helping: “I/O virtualization brings these principles to the edge of the network. Its general goal is to eliminate the inflexible physical association between specific network interface controllers (NICs) and host bus adapters (HBAs) and specific servers.”

The next step will be to extend these dynamic principles from VMs and I/O, now to the network.

Where we need to focus attention

Wayne Gretzky once famously said he "skates to where the puck is going, not to where it is."  We’ve seen where OS virtualization is taking us. But let’s now anticipate where IT network operations will go in the future.

Let’s begin again with an OS virtualization analogy: Take VMware’s DRS – which orchestrates the creation, scaling and migration of VMs dynamically as demand changes.  It’s a great illustration of workload management adapting to demand and to utilization. Similarly, we’d expect infrastructure to have similar dynamic properties - I/O, network switching, balancing, security and even inter-datacenter connectivity which would need to have the same level of fluidity.

Think we’re there now? Think again. Here are some use-case examples that just don’t have generalizable solutions yet – (whether in the physical or virtual server world):

• Local Server repurposing: A server farm sits behind a firewall; each server has a specific I/O configuration, and needs access to a load balancer to handle spikes in traffic.  Problem: if a server in this group should fail – or should more servers need to be added – only servers in that physical cluster (which have been configured with specific I/O) can be swapped-in.  No others have access to the firewall or load balancer.
• Virtual server migration to a new datacenter:  Say you have a VM on a specific VLAN behind a specific firewall. And you want to live-migrate that server to a remote datacenter.  Good luck with that – the firewall probably won’t be available, nor may the addressing be available (or portable) and neither may be the VLAN.
• Environment failover: Now, say you have a complete server environment whose topology includes both physical and virtual servers, switches, load balancers, firewalls and VLANs. Now say you need to re-create this environment elsewhere due to a disaster.  Your best hope is a team that can identically re-configure this topology fast (or, you have a warm recovery datacenter just waiting in the wings). But today, your options are limited in being able to accomplish this in SW.

Just a reminder here: OS virtualization is not the answer to any of the use-cases above. Rather, what we ideally want to solve for is a dynamically-reconfigurable infrastructure – one where network components are able to be created and implemented on-demand. (This is not unlike Lori MacVittie’s recent observation of AWS’ dynamic load balancing and scaling, where in effect, load balancers can be defined and instantiated in software.)

The completed analogy: the next step for the data center

The punch-line here is that there needs to be analogous “2.0” functions embedded in the network/infrastructure to what we already are familiar with in the software realm. Take for example:

• Infrastructure abstraction – allows for logical provisioning of I/O, networks, network devices, storage connectivity and network devices in software; analogous to the creation and placement of virtual workloads in the software space
• Infrastructure consolidation – by defining I/O in software, and by using converged networking, this greatly simplifies utilization and configuration of the physical infrastructure; analogous to logical consolidation of VMs and their workloads
• Dynamic networking – networks, multi-pathing and addressing that adapts to sizes and locations of workloads, as well as adapting to failures and bottlenecks. Roughly analogous to high availability and wide-area migration services that are delivered in virtual OS environments.
• Logically-defined load balancing and security policies – where IP load balancing, firewalls, etc. can be invoked for any processor in any location, and where IP loads can be distributed locally (or globally) on-demand; roughly analogous to virtual scale-out services and grids.
• Dynamic QoS management - allows for optimal use of network capital, and (hopefully) best infrastructure efficiency; this is analogous to dynamically managing CPU utilization in the software world.

Parting words of sobriety

While this idealized picture is only a future, there are certainly companies and products beginning to chip-away at the market. But point-products (non-systems solutions) are never the entire answer. Rather, it’s high-time for the industry to begin to think about an approach to address this space. Like most industry maturity models, I would expect to see something like the following evolve over the next few years (these things take time):

1. Point-products:  That address specific issues e.g. I/O virtualization,  converged network techs, software-based network mgmt appliances
2. Industry awareness:  For example, developing what the “infrastructure 2.0” working group is proposing
3. Common communications:  APIs and protocols to allow interoperation of the infrastructure components and their logical configuration
4. Standards-based innovation: e.g. the DMTF or similar standards organization take on this set of issues for broader adoption
5. Automation: A broader set of tools get developed to orchestrate the infrastructure similar to what we’re seeing in the VM space

And finally: Technology is only part of this story.  But there is also the fact that any form of automation/abstraction will massively impact IT operations, and therefore will butt-up against organizational structure, jobs, roles and people. So the sooner we recognize both the benefits and organizational impacts, the sooner we’ll be prepared to gladly absorb the changes this approach to infrastructure management will cause.

Ken Oestreich is VP of Product Marketking with Egenera, a frequent blogger as Fountainhead, and can also be found quipping on Twitter.