Virtualize Me!

Virtualization changes everything -- a saying that's becoming more and more true as this revolution in computing spreads throughout the industry.

If you're an IT vendor, this is a big deal.  If you're an IT user, this is a big deal.

And if you're in between those two -- say, an outsourcer or system integrator -- this is a big deal as well.

I had a great session with one of EMC's outsourcing / SI partners last week.  Many of their clients had started to ask "virtualize me!" but the answers weren't always easy for them ...

It's No Surprise

If you're in the business of providing IT services -- whether it's of the system integrator variety, outsourcing variety, or a combination of both -- I would bet that the whole virtualization discussion comes up more often than not.

Most IT users realize that virtualization can save them money -- that much is clear.  But where it gets hazy is figuring out the appetite for "better IT" -- infrastructure that's more responsive to business requirements, in addition to being more cost-effective.

The other challenge is that the range of VMware use cases we're seeing keeps expanding.  You can't just generalize on "what do you recommend for VMware" anymore.  It's like asking "what do you recommend for servers" or "what do you recommend for databases".  The range is becoming pretty broad.

VMware clearly isn't just tier 3 applications, or test and dev anymore.  As an example, some people are putting surprisingly large applications on VMware these days.  Or we're seeing larger and larger VDI projects which force a different set of concerns.  And we're seeing scale-out of VMware farms that we hadn't seen just a year or so ago.

All of these use cases aren't generic.  Indeed, we've got an informal taxonomy of a half-dozen or so primary use cases, and more are being added all the time.  And, in many cases, the differences are more important than the similarities.

So, where to start?

Virtualize Me -- And Don't Change Anything

First off, this partner was encountering a few clients that were looking to virtualize a portion of their environment -- but didn't want to change a single thing. 

No new hardware, no new software, no new process and procedure -- they wanted just what they had before, only make it virtual.  And save a bunch of money in the process, please.

Imagine trying to execute a successful virtualization project at reasonable scale, and having to use three-year old servers that hadn't been updated in a while, some random mix of internal and external storage, application and infrastructure software that hadn't been qualified -- let alone designed -- for a virtual environment.

And that's in addition to not being able to significantly touch the IT organization's run book, e.g. the process by which things get done on the floor.  Now, many of you are probably shaking their heads and rolling their eyes at this, but there it was.  And they wanted my opinion on the matter.

Simply put, I though it was a bad business to be in.  Why?  The client in this case has very unrealistic expectations.  And -- in any business -- clients with unrealistic expectations tend to be more trouble than they're worth.

Could you make it all work, technically speaking?  Sure.  But I believe that the outcome would generally be so sub-optimal, you really have to ask yourself "why bother?"

Our partner would have to either invest in the cycles to reposition the engagement around at least a decent element of value generation (rather than cost avoidance), or they're probably better off walking away and letting someone else take on that particular meat grinder.

It's All About ROI

Sure, every IT project needs some sort of return on investment to justify the investment and effort.  But how are you measuring it?

One of the challenges this partner had was framing the ROI discussion appropriately in the context of virtualization projects.  Seems that -- at least for some of their clients -- the discussion was almost entirely focused on saving easily identifiable costs (e.g. server costs, storage costs, energy costs).

In these cases, there wasn't much interest in quantifying potential operational savings.  Or, more importantly, quantifying the value of being more responsive to new demands from the business, or providing better HA to more applications, or being able to better support older legacy environments, or getting new versions of applications up much faster, or being able to dynamically optimize pools of resources, or ...

You know, all that hard-to-measure stuff.

Now, there's nothing wrong with a hard-nosed focus on easily identifiable costs.  But -- at least in the case of virtualization -- I think the impact of these harder-to-measure benefits are an order of magnitude greater than the easy-to-identify cost savings.

And -- worse -- success or failure of the project will hinge on meeting the easy-to-identify savings goals, and may potentially ignore all of the other hard-to-measure benefits.  You end up getting what you're measuring for.

And if you're not measuring "better IT" as part of the engagement, you probably won't get that as an outcome.

I suggested that it might make sense to think in terms of an increased investment in getting more proficient at identifying and quantifying these virtualization benefits that are harder to measure than just simple components.

As a backdrop, I also pointed out that we're seeing more and more clients who have crossed the "philosophical divide" when thinking  about virtualization and VMware.  They've crossed the chasm, so to speak, and are thinking of this more of a way to deliver better IT, rather than simply a cost reduction technique.

What About Hyper-V, and Xen, and ...

Very good question.

Yes, there are alternative hypervisors out there.  And, yes, EMC is qualifying and supporting most of the popular ones.

But, that being said, just about every customer we talk to would rather just get on with it, rather than waiting longer for these other environments to mature.  So -- at least for the foreseeable future -- it's pretty much a VMware-centric discussion for our customers.  Yes, we get involved in the occasional tire-kicking with other environments, but there's a lot less of that than you might think.

These customers tell me that the stakes -- and the impact -- are just too great to be delaying projects waiting for a viable alternative to emerge.

And then the discussion turned to products and technologies.

What Storage For VMware?

Another topic that they were getting wrapped around was the question of "what's the best storage for VMware?" and the inevitable protocol, technology and vendor debate that ensues.  Rather than a standard "it depends" answer (which I categorically dislike), I took a step back and drew a different picture.

Imagine your client is on a journey with VMware and virtualization.  For their first engagement, we're probably talking something very small and relatively unimportant to get their feet wet, so to speak.  Maybe it's a piece of a test and dev environment, maybe it's a few unloved applications -- whatever.

So you're probably talking either (a) reusing a shared storage device they already have, or (b) something that's very easy to configure and manage, like NAS.

For the second engagement, there's probably another bunch of servers involved, and the stakes are probably a bit higher.  Maybe something like iSCSI to keep the costs down, yet deliver a SAN-style model to better take advantage of advanced VMware features.

And, finally, keep in mind that we're now seeing lots of serious applications end up being virtualized: heavy-hitting Exchange, Oracle, SAP, SQLserver and the like -- so the right answer here ought to be the same sort of storage technologies that we see in the physical world for these same applications, e.g. FC SAN.

Since it's a journey for most customers, it's better to think of things being right at certain points in time, rather than "right" in an arbitrary sense.  But, at the same time, you don't want to end up with multiple storage platforms unless the scale and the resulting benefits justify the specialization.

As an example, I pointed them at EMC's NS40 unified storage platform as an interesting hedge bet in these situations.  Since it does NAS, iSCSI and FC all at the same time, as the customer's comfort level with virtualization increases, you simply add protocols as things evolve. 

There's NAS for those getting-your-feet-wet engagements, or perhaps supporting test and dev -- very easy to configure and manage.  Add iSCSI support for a slightly larger farm where you'd like a SAN model, but can't justify FC. 

And, of course, real-deal FC support with underlying CLARiiON technology for those applications where application performance really matters.

All on the same box, at the same time, and -- of course -- with the full boat of VMware integrations and qualifications.  Pretty easy to manage, as well.  And, since the product is essentially modular, there's all sorts of options to upgrade storage, features, front-end connectivity, etc. as things progress.

And How About Backup?

There was another flavor of this discussion swirling around backup as well.  This partner had already seen what can happen when 10 or 20 physical servers get consolidated into a single virtualized server.

I drew a similar picture to the different storage use cases.  Many VMware environments have plenty of headroom to support a client-side deduplication scheme like Avamar.  The benefits of less data sent over the wire, less data stored, slick integration with VMWare, etc. -- it's our first go-to choice for most native VMware deployments.

But, since we're now seeing an expanded set of use cases for VMware, our recommendations have to expand as well.

Imagine you've got a big Exchange environment, or SAP, or Oracle.  In the physical world, you've probably optimized how you do backup and recovery for these bigger applications, and probably don't want to go back in and re-engineer everything.

Hence an increased interest in disk libraries for these environments, especially ones that can do deduplication as a post-processing function rather than take the hit for in-line deduplication.  VMware VCB integration can be a useful "booster" in many of these environments to separate backup activities from production activities -- as are the wide range of local replication tools such as TimeFinder and MirrorView.

And, Of Course, Remote Replication

We spent a fair amount of time talking about what VMware's SRM (site recovery manager) brings to the table in DR and BC environments.  Sure, there's always the appeal of using less hardware, but the real kicker is the ability to configure and test failover using a "virtual playpen" without disrupting production activities.

Combine VMware's SRM with newer forms of remote replication (e.g. EMC's RecoverPoint), and you're talking an entirely new cost structure for remote site recovery proposals -- capex and opex.

Indeed, I shared that we were meeting a few customers who realized that the cost savings of doing remote replication in a virtualized environment probably more than paid for the cost of virtualization itself -- kind of an interesting tail-wagging-dog scenario.

And, Ultimately, Shifting To Value Generation

This particular partner was pretty far along in their thinking around "utility" VMware-based farms that offered generic containers for computing: whether on the customer's premises, or at an outsourcing facility.

But it was pretty clear to me that there was a huge opportunity to leverage their existing capabilities to offer new solutions to their clients.  Things like fast provisioning of new environments.  Or the ability to tier service levels (performance, backup, HA, etc.) up and down dynamically.  Or perhaps a new set of business continuity offerings targeted exclusively at virtual environments.

Lots of possibilities.

But each of them was based on a core premise -- that virtualization could not only save you money, it could deliver better IT -- infrastructure that's more efficient, more flexible, more responsive and more resilient than most of the stuff we build in the physical world.

And that's the real opportunity with this stuff.

Comments

[Barry Whyte]

Of course I'm going to since the SVC song here, but in your "what storage for VMware" section its interesting at no point you mention Invista.

If I were discussing this with a customer, then maybe the question of flexibility of access would come in.

With an iSCSI router backed behind some cheaper FC or SAS based storage would work, while combining this with SVC. That way as you add more and more to your virtual environment, and the heavy hitters come in, then you are still provisioning storage through the same device and the same way you did when you were playing with test and dev systems. Then it doesn't matter what storage you buy, you add more of what you need when you need it, in the tier you need it - and if you end up needing a DMX then you can even add that behind the same interface and provisioning interface... I guess thats just one of the places SVC has a major advantage over Invista - entry level cost... not to mention not needing that DMX or high end box, just a selection of multi-vendor (best bang for the buck at the time) mid-range RAID boxes. Take the decision out of what next based on features, simply who can give me the performance and capacity I need this quarter. Sound simple... it can be... and many of our mutual customers would agree.

[Chuck Hollis]

Hi BarryW -- Glad you left a comment, I was missing the cheerleading ...

Funny, I've found almost *no* interest in block-mode storage virtualization (from any vendor, at any price) with the current serious VMware deployers.

If I had to hazard a guess as to why this might be, the answers might include:

* not wanting to complicate things with too many moving parts (e.g. SVC or alternative)

* think that VMware's "storage Vmotion" might be all that they need (true for more than a few use cases)

* concerned about end-to-end storage management issues.

Good luck out there, BarryW.

BTW, what are the plans with SVC and XIV? Looks like the XIV architecture might do a fair amount of virtualization on its own ...

[Barry Whyte]

Interesting take as always. We are finding the opposite, those that see the value in host virtualization, can see what storage virtualization can also bring to the party, and that they need to consider the same issues with both, peak loading, shared infrastructure etc etc

Vmotion does provide a nifty way to move host to host, but you still need that way to move storage to storage, or vendor to vendor....

I was recently suprised to learn that in all the miriads of wonderful EMC management software, by default you don't provide a means for your customers to measure response time - and they have to resort to freeware to get such insights. Said same - major EMC DMX and Clarrion deployer was amazed that SVC provided end to end statistics allowing both virtual and physical devices to be monitored - thus eliminating the need for the free-ware clunky products, and also showing the physical devices for what they were...

So end to end management and monitoring can only be easier in such an environment.

As for SVC and XIV, it will be a supported SVC storage device, and yes it provides virtualization in the sense of RAID (as most controllers do, EVA, USP, DMX), but cannot yet cross the vendor / storage controller device boundary, so there is still a place for block virtualization, even if you make the decision to use XIV to provide SATA enterprise arrays.

[Chuck Hollis]

First, BarryW, I'd suggest you might want to get briefed on "Storage Vmotion" which *does* do array-to-array moves, and thus is a candiate for storage virtualization done on the server, rather than switch/appliance/array approaches.

As far as end-to-end response tools, we have more than we can use. I can't speak to the specifics of the customer you were talking to, but -- categorically -- not an issue.

More interesting are things like provisioning, capacity utilization, root-cause problem analysis, encryption and key management, etc. It'd be very interesting to see what SVC does for those things as well :-)

As far as XIV, yes, good to here it'll be a real part of the IBM portfolio, since the message is a bit unclear externally. But -- you'll have to admit -- part of the "SVC is all about using cheap storage" message gets diluted a bit in the face of cheap XIV storage.

Wait a moment, I'm wrong! XIV is the expensive stuff, right? Sheesh, we can't figure it out -- can you help?

:-)

[Steve Chambers]

Hey Chuck, good article (and comments!).

I've got an update for you - VIOPS is live at http://viops.vmware.com/home

We are launching it at VMworld 08 so still a few things to sort out.

I didn't see you as a registered user so thought I'd bug you again :) hope you don't mind!

We have some changes due this week like replacing the graphics with nicer ones, and putting the Community zone together better, but the rest is finding and adding content...

Sounds like you've been on your travels - hope the 'lag isn't hurting too much - are you going to VMworld 08?

[Chuck Hollis]

My bad -- I'll be by soon!!!