Virtual IT: A Frictionless World?

Welcome to our parade of next-gen IT topics for the next five years.

We got started by discussing how IT context might change over this period here and here.  We went a bit further and discussed about the deconstruction of physical IT infrastructure thanks to our friend virtualization, and the re-construction of services using a model paradigm.

And, most recently, shifted the perspective to our end users, and how their needs will evolve over this period.

Friction and Physics

You've probably seen what happens at near-absolute zero in the lab -- things behave very differently. 

Electrical resistance can disappear, resulting in superconducting.  And superfluids allow near-frictionless motion: start something spinning, and it'll stay spinning a good long time.  Cool stuff :-)

Simply put, the world is a different place when you take a lot of the friction away. 

As I'm about to be reminded as winter sets in here in the Northeast, and we'll at some point be coated in an attractive layer of sheet ice.

And we're in the process of seeing all sorts of friction come out of IT these days:

• The advent of global high-speed networks removed one form of IT friction -- distance matters a whole lot less in many circumstances. 
   
• The advent of widespread virtualization means that computing can eventually be moved to anywhere it needs to be run, simply because it's living in a nice, self-contained wrapper. 
   
• And as replication technologies evolve in lockstep, we'll see progressively larger information stores appear when and where they're needed in the global network.

If friction is coming out of IT, what forms of superconducting and superfluids might we see in this new world?

VMware: A Taste Of Supercool

Proficient users of environments like VMware's DRS have already gotten a close look at one form of friction removal: not only are available compute resources dynamically optimized and load-balanced, you get things like N+1 availability clustering for "free".  Because a major source of friction has been removed, workloads balance much faster, resulting in very high utilization rates.  And, of course, the notion of HA has been somewhat redefined, hasn't it?

In many regards, it's a version of the perfect IT trifecta: faster, better and cheaper.

As you think about it, other forms of friction have been dramatically reduced as well.  It's far easier to spin up a new "stack" or container than before.  Moving to new versions of whatever is greatly simplified, because rollback only takes a moment or two if there's a problem.  And this year, as SRM came into the marketplace, the effort associated with remote recovery also got seriously redefined around "less friction".

But does the business benefit from all of this as much as they could?

Sandbox Computing

Today, when I want to store a shared file, I don't have to submit a request, offer up a cost center, or go through a detailed review.  I simply do it.  And, as long as I don't burn through too many shared resources, everyone is better off.  Especially me.  I like this frictionless approach.

The same thing works on our internal social media platform.  If I want to start a community of like-minded people, I just do it.  No real heavy lifting involved.  Now that I think about it, there are lots of similar services in many corporate IT environments that are just "there" for the taking.

And, in general, the benefit that accrues to the business from speed and convenience is more than outweighed by any benefits that accrue from over-managing the resources.  Removing friction is generally a good thing.

How is asking for a virtual machine all that much different?  It's a file loaded on a server when I need it, and the server resources can be used by someone else if I'm not using it at that moment.  What's the big deal?

In a world where I can cram hundreds of active VMs on a single blade -- just like I can cram hundreds of users onto a single file server -- why will we need the these heavy-duty, friction-laden IT processes just to get a half-decent compute image in a few minutes? 

Why can't I just pop up a quick form, click a few boxes, and get my compute environment pre-loaded?

Indeed, I'm starting to meet a few more progressive IT shops that are looking at things the same way.  They don't overly sweat the use of other corporate shared IT resources like file, print and network (within reason, of course), why should smaller and less-important compute images be anything different? 

Their people have ended up monitoring the overall sandbox environment, and tend to focus on the few exceptions that emerge, rather than the general case.  No different than a shared network, or a shared file server.  And everyone seems to be happier: the users, the business, and especially the IT guys who would rather just give people what they want and get on with it.

Friction has been removed.

Outsourcing Redefined?

For the last few months, I've started to meet more people who were well down the road of virtualizing very large environments.  And they're starting to ask an interesting question: do I really want to own all these servers and storage?

As a result of their VMware experience, their perspective has changed. 

All the 'value' has moved to what's inside the container: the business logic and how it ties with other applications.  Not so much value is derived by standing up the servers and storage behind it.  And they're starting to look around for service providers who can run their containers at the appropriate service level -- and the appropriate price.

Of course, IT wants control of their environment -- they're on the hook to the business for the "what", not the "how".  And to do this, they'll want the option to control not only the software stack, but to control various service levels, as well as data protection, not to mention network and information security. 

And those control-oriented technologies are coming along nicely -- sooner than later, as I see it.

In this near-term state, the "cost" (or friction) associated with a move from one environment to another has come down considerably, thanks to virtualization -- at least, as compared with traditional outsourcing approaches, which opens up an entirely new line of thinking in terms of where things run, and why they run where they do.

A Really Big Cluster

Back to our small-scale ESX cluster running DRS, we see how things get faster, better, cheaper simply by taking friction out the equation.  It's cheap and easy to move a running task from one node to another, so you can do it all the time for cost reasons, performance reasons or availability reasons.

And, generally speaking, the bigger your cluster, the bigger the advantage, right?

Now, let's extend the notion of cluster to multiple data centers.  Maybe even data centers that you don't own, but perhaps simply rent a bit of container space when you need it.  Maybe you own some of these servers, maybe you don't.

Could you get a cost advantage? 

One way is by leveraging the economics of container providers who can theoretically do a better job simply by having the option of much larger scale.  Or perhaps getting access to cheaper local power and labor.  There's also a potential cost advantage in swing capacity: you don't have to overprovision the servers you own for "worst case" scenarios.

How about a performance advantage? 

Sure, it's easy to see that you could specify a dynamic service level to keep most everyone happy.  But there's a more subtle angle to this as well: the ability to locate applications (and their information) closer to users in a globally networked environment.

Someone in China doing end-of-the-quarter closing?  Ship them a virtual container (possibly hosted by someone else) that puts the application and the information close to where the work is being done, and bring it back later.

And, of course, there's availability as well.  In a world of N+1 geoclustering, business continuity gets an entirely different perspective.  Much like N+1 HA in a DRS cluster, you get most of it for "free".

One Minor Detail, Though

We already see the virtualization part of this equation at work.  Going a bit farther, I can see where the management technology would come from.  I can also see the basis for security and information risk management in this scenario.

But I think that remote replication will need a little extra special technology juju to make this all work.

For applications that don't really care that much where their information might be located on the global network, there's not much of an issue.  Especially if you have really patient end users.  Or, conceivably, if the applications and their associated information is relatively small, you can see things kind of working.

Now, envision a terabyte-class high-volume application being moved six timezones -- with no visible downtime.  Or an application being split into six "children" -- each with its own data store -- and re-integrating the pieces when the storm passes.

It's pretty clear that our existing models of replication will have to evolve a bit to support these kinds of scenarios.

Friction, Friction Everywhere

For the last year or so, as I listen to what our customers want to get done, I'm usually thinking in terms of some aspect of friction reduction.

"We need to be more efficient" == reduce friction
"We need to be more responsive to the business" == reduce friction
"We need to improve our internal processes" == reduce friction
"We need new strategic options for IT" == enabled by reducing friction

In my mind, one of the most powerful themes over the next five years is are the twin notions of "friction reduction" and "improved management control".  Make it easier to get things done in new ways, but at the same time evolve the management and security tools to thrive in this new frictionless world.

And, as I think about "virtual data centers" and "virtual IT", I'm starting to realize that it probably won't have a specific address before too long.

Courteous comments welcome as always!

Comments

[Maurice Gavin]

Great post, looking to learn more about the idea of frictionlessness, and would like to reach out again as I get my head further around this idea