I saw a post from Cesar Diaz on Twitter today:

Ended day on exhausting telecon with developer insisting virtualization was for testing only, never production and just a fad.I need a beer

In my five years at VMware, this has been one of those top 10 barriers to virtualization. But you know what, it’s kind of my fault.

This article explores:

• Why it might be all my fault
• Typical Application Owner barriers to virtualization
• Six ways to get over this virtualization barrier
• Why low hanging fruit was wrong

Why it might be all my fault

It’s my fault because I was one of those in the early days who looked for an easy way out after being pulled aside by a Senior Director at a UK Bank:

Steve, VMware won’t be successful in here because we, as an institution, won’t be able to adapt to it. That means it will end up on The Error Report, not because VMware technology doesn’t work, but because our people and process won’t be able to adapt.

This was more of a plea for help than a request to leave the building (I think…) so with true Yorkshire Grit (two parts coal, one part sand) I devised a cunning plan:

If we only virtualize the “low hanging fruit”, like Test and Dev, where any outages don’t end up on The Error Report, then that’s a safe route to show that VMware technology works!

And so that’s what we did then, and it’s what ten’s of thousands, if not more, VMware customers have done since. But there’s something wrong with this approach, isn’t there?

What are you thinking right now, which one of the following are you:

• Slap your left thigh if you are thinking “Seems good advice to me!”.
• Stroke your right thigh if you are thinking “No! No! No! Virtualize the hard applications first!”.

If you are a Slapper, then I’m sorry but you are wrong. The Strokers are right. I was a Slapper and I regret it, because by being a Slapper I’ve done my part to hold back virtualization. And here’s why:

At some point in the road to full virtualization, where you are running a high performance datacenter with better throughput of change and lower costs than the average datacenters, well somewhere along that road you hit a specific roadblock we shall call an Application Owner.

Typical Application Owner barriers to virtualization

This Application Owner has a war chest of excuses not to run their application on VMware. Here are a few, of which we shall dwell on just one for this barrier:

1. Server Hugging – it’s my server, I want to feel it, touch it, hear it, smell it – but NEVER share it!
2. Religious Blinkers – sorry, but my way is the true way, my application is certified on this platform and all other platforms are False Prophets.
3. Nowt For Me – so you, Mr Datacenter, get to save on power costs, but what do I get out of it?
4. No Added Value – a bit different but related to Nowt For Me, this instead is born of a Fear And Loathing of the “IT Ops Dullards” – yet another change that adds no value to me and my application, just like that upgrade of the cooling system.
5. Fit For Purpose – many manifestations of this, from Real Time Needs through to Massive Capacity Projections – in our Capacity Planner engagements, less than 5% of total servers need anything like the App guys say. In fact, there are more apps that exceed the App teams requirements because once they open the door to real traffic, the App can’t take it. But I digress…

This last category, Fit For Purpose, is where Virtualization Barrier #2: It’s Just for Test and Dev fits. Some common objections by the Application Owners:

• The application requirements state hardware requirements for a performance level. For example, to handle 100,000 queries you need a dual core CPU at 3GHz and 2GB RAM.
• The application vendor does not explicitly support or explicitly does not support their application on VMware products.
• We tested the application on VMware once, and it was crap. <– never any data to back this up, just solid conjecture.

I’ve heard all three of the above, and if you would indulge me I’d like to quickly cover each one before going through some possible answers / crutches.

The Application Requirements objection, such as “my application needs to run on a Xeon quad-core” can be addressed by education about how ESX works. Best done by sitting the App Owner in front of vCenter and a VM and getting them to look in Device Manager for Windows (or similar for *nix) and loading their app and doing one of the many available tests, or just a “sniff” test where they play with the app. This could be a lunchtime Brown Bag session.  A VM is like the latest new care: “Take her for a run, see how she feels, I know you’ll be impressed.”

ISV Support used to be a PITA, but now it is better and not least because of the VMware ISV Center helping customers take the high ground against change-resistant ISVs who, through their own self-interests, were in effect suppressing their customers’ move to virtualization and all the benefits they might get. Oracle is the remaining Angry Grandad in the corner who talks about The War and can’t move with the times. Poor , Angry Grandad

Only last week I met a Technical Director with arms crossed (I like and understand body language, but you didn’t need to be an expert here!) who said virtualization was “too much of an overhead” and not good enough for his applications. When asked when he’d last had a good look at ESX, he said “2003″. Well, the changes in performance between 2003 and 2009 are a bit like the changes in transport from the 19th Century and today. They still have the same shape, four wheels etc., but the performance and efficiency improvements are dramatic. Even the difference between ESX 3.0 and ESX 3.5 are dramatic. vSphere 4 is another Giant Leap for Virtual Kind.  See real world data on today’s performance of vSphere.

So, after all this negativity, the Application Owner is going to throw you a bone: well, I suppose we could use it in Test/Dev. We now have an opening.

Six ways to get over this virtualization barrier

If your Application Owner is refusing to allow their applications to be virtualized, and/or restricting it to Test/Dev, here’s some successful approaches I’ve used in small and large organizations alike. These approaches are in ascending order of harshness, but it depends on your situation and organizational culture. If, at one end of the spectrum, your Application Owners are Masters of the Universe, then start with #1 SILENCE, if you can. If, at the other end of the spectrum, you deliver servers like electricity and Application Owners are not allowed to care about what platform they run on (do they choose the CPU type? Because there IS a difference between Intel and AMD), then short-cut the process and you can probably jump from #1 SILENCE to #6 FORCE!

1. SILENCE. They are buying a service. As long as you provide the same-or-better service, what has it got to do with the App Owner? This means you have to be 100% sure in your P2V or Build process, and be sure that performance as seen from the user and service end is as good or better.
2. CHARM. Understand the Application Owner. Using this article and the resources on vmware.com (ISV Center, Performance etc), list the concerns on a whiteboard and work through those concerns seeing the world from their angle. If you can’t convince yourself that each concern can be realistically overcome, then don’t push them. You should be able to overcome all of the concerns One thing all Application Owners appreciate is the ability to recover from their own mistakes: so sell them on Snapshots, sell them on refreshing environments in a day instead of a week, help them be successful.
3. BARTER. Accept the Test/Dev limitation, but with a condition. If the application works in Test/Dev that proves it works on ESX, full stop, and you can run it on Staging and Production. If not, what are the other reasons (see later).
4. BRIBERY. Now or next year? Usually the biggest pressure on Application Owners is time and money. If you can deliver, and refresh, and environment in days instead of weeks, they will be eating out of your hand. Hit the Project Managers with this!
5. PRECEDENT. Virtualize a more important application first. This is the killer, and this is what I’ll finish the article on.
6. FORCE. Invoke executive orders. Why are you virtualizing? Is this a bottom-up or top-down project? If top-down, have you got mandate from the CIO that can be used to get Application Owners inline.

Why low hanging fruit was wrong

I made a mistake all those years ago when I said “virtualize the low hanging fruit first”. It was the easy path to build up a number of VMs to show that VMware technology worked. It was low risk, it gave customers benefits, so perhaps it wasn’t bad but it might have been short sighted.

At some point you WILL get an Application Owner who will stand in your way, and one of the most effective of the six approaches is #5 Precedent. When the Apache Web guy says “Virtualization is only good for TestDev”, and you show him how your production Exchange cluster is running all 50,000 users, and how ESX has the highest SPECweb performance of ALL platforms, then he/she might want to rethink before you move to #6 FORCE.

A customer in Europe told me at the end of last year, “Why wouldn’t we virtualize Oracle, Steve? It works perfectly well since 2006! We don’t see what all the fuss is about!”. I asked them why they virtualized Oracle first and they said “Because if we could virtualize the Tier 1 application successfully, then there is no excuse for the rest!”

And that is why I’m kicking myself that I didn’t have that kind of thinking five years ago, because although Low Hanging Fruit has helped thousands of customers get going with virtualization, and perhaps it was most appropriate back in those days, vSphere is in such a different league than ESX1.5 / ESX 2.0 that today the opposite is true: go for the Tier 1 apps.

So I’m sorry, Cesar Diaz, that you are STILL hearing about stubborn Application Owners in 2009! Part of it is my fault, but I’m doing something about it, honest

Related posts:

1. Virtualization Barrier #6: The Application Developer
2. Virtualization Barrier #1: Manual Processes
3. Virtualization Barrier #3: VMware is Too Expensive
4. Virtualization Barrier #4: The Network Engineer
5. Virtualization Barrier #5: The Storage Manager