Virtual IT: Deconstructing Infrastructure

Yet another step in our journey at looking at future-state IT in five short years.

The first two posts (here and here) spoke largely about how the business will view IT, and how IT might come to think of itself.

The third post dealt with the first of several important constructs (orchestration) that I believe will be essential in this future state of virtual IT.

Now, let's dig into virtualization itself, but from a slightly different perspective -- the deconstruction of IT infrastructure.

What's Infrastructure?

At one level, it's the stuff you can see: servers, storage, networks.  But -- pushed a bit farther -- the concept can also be stretched to include software entities that provide shared services on the behalf of others: databases, middleware, operating systems and the like.

Most people would recognize that we've begun a secular industry trend around virtualizing many aspects of what we consider physical and logical infrastructure.

But what's really going on here?

VMware, Leading The Charge ... Again

If you listened carefully to Paul Maritz' keynote at VMworld, at one point he spoke quite eloquently about the "deconstruction of the operating system".  That thought resonated with many people, and I for one saw that he was pointing to but a single example of a much broader theme -- the deconstruction of infrastructure.

To paraphrase his views, we started with operating systems serving two roles: providing shared logical services to applications, and managing the underlying hardware resources.

What hypervisors do in general, and VMware specifically, is split these two roles neatly in two.  You're free to have different flavors of application services (operating system versions, databases, etc.) neatly running in any container you choose.  But, with virtualization, there's a standard way of mediating between that world and the world of physical infrastructure.

Application people get what they want -- an environment tailored to their needs.

And infrastructure people get what they want -- a standard enabler to optimize and coordinate IT resources.

We no longer have to live in a world where we have Oracle, Exchange or SAP trying to run physical infrastructure as it sees the world.  Or multiple flavors of Windows, Solaris, AIX and Linux trying to do the same thing.  Or any other hunk of software, for that matter.  In a server virtualized world, these environments are all about giving the application the environment it wants, and far less about touching physical entities.

Not to oversimplify, but we've now separated "what applications want" (e.g. application services) from "how they're provided" (e.g. shared infrastructure services). 

Indeed, in the fullness of the concept, we've also created isolation from "where they're provided" or "who provides them".

This is a very disruptive line of thinking. 

Just ask Microsoft, Oracle, any traditional server vendor, outsourcer, SI, etc ... :-)

But Let's Not Stop There, Shall We?

We've seen this same generic concept become successful in the networking world already (VSANs, VLANs, MPLS, etc.).  Here's the network topology and characteristics you need to support your application -- completely and utterly isolated from how (or where, or by who) that might be actually done.

The same conceptual view can be found in storage virtualization, regardless of who's implementing it.  Here's the storage capacity and performance/availability/recoverability characteristics you need to support your application, totally and utterly separated from how (or where, or by who) that gets done.

And, if you're still with me here, let's step on up the stack a bit.  Can't we use the same line of thinking for backup and archiving services?  Database and repository services?  Security services?

Keep on going up in the atmosphere until we start to realize that we're not only virtualizing infrastructure, we're essentially virtualizing application compositions themselves (although we use different words to describe the concept, don't we?)

From Efficiency To Dynamicism

The first wave of server virtualization was largely driven by an interest in using hardware resources more effectively.  I'd argue that this has played out more dramatically when considering server virtualization than other forms.

The larger the pool of server assets we were virtualizing, the more pronounced the benefits.

But, if you accept some of my assumptions and predictions from earlier posts, the primary value associated with virtualizing and deconstructing infrastructure will move sharply towards the ability to change things quickly.

From something as simple (and pragmatic) as quickly provisioning an application stack, to dynamic load balancing in a cluster, to more advanced aspirations around geoclusters and vClouds -- we'll probably see more and more focus being put on the ability to react more swiftly and predictably to change, rather than driving the last few decimal points out of utilization rates.

And, once again, the larger the pool of assets we're virtualizing, the more pronounced the benefit.

The "Shipping Container Analogy" Reprise

Sorry if you've heard this before, but I frequently use an example from outside of IT to illustrate the point.

Back in the day, if you wanted to ship a lot of stuff around the world, you loaded up a truck with your stuff. 

The truck went to the train station, where it was laboriously unloaded and reloaded.  The train went to the dock, where the process was repeated.  And, when the ship arrived in its new port, the entire process was repeated in reverse.  Not ideal in several regards.

Enter the shipping container.  Pack all your goods in a standardized and protected container, and tell the freight forwarder where it had to be, and by when.  Your goods were quickly and easily moved between different modes of transportation, and protected along the way.  You really didn't care too much about the gory details.

Shipping infrastructure changed also.  Trucks, trains and boats were optimized to handle the new containers.  Loading and unloading equipment was redesigned as well.  Eventually, people started tagging the containers so they could be tracked in real time.

The more the industry adopted the concept, the more pronounced the benefit for all players: customers and providers.

In short order, an entire industry was remade around a single, powerful concept.  Not only was it cheaper to ship goods than ever before, it was more reliable and there were fewer indirect costs involved.  As a shipper, you now had lots of providers to choose from, and -- more importantly -- all sorts of flexibility in trading off between speed and cost -- even as your goods were en-route.

Back To Virtual IT

We now have a fourth meaning for the term "virtual IT", perhaps the most obvious interpretation among many.

• Deconstruction of physical and logical infrastructure. 
• Encapsulation and abstraction between "what" and "how", "where" and "who". 
• A secular shift in interest from cost optimization to flexibility and dynamicism.

Among all the concepts we'll discuss on this broader topic, this one is perhaps the most substantial and far-reaching of them all -- it makes everything else about "virtual IT" feasible.

And, of course, VMware is leading the charge.

Courteous comments welcome as always.

Comments

[Tarry Singh]

Chuck,

A bit off-tangents question

Are you in Amsterdam for the Gartner Data Center event?

You can mail me at tarry.singh AT gmail(DOT)com

Tarry

[Martin G]

Well if you follow the shipping analogy, we're going to see some crazy consolidation in the industry. I wonder what the TEU of the virtualised IT world will be (I worked in shipping for a bit, did you know that custard powder is a dangerous cargo?).