Feeding the IT Shriekometer: 5 VDI anti-patterns

Virtual Desktop not working? Prime the IT Shriekometer!

Are there some universal anti-patterns in Virtual Desktop Infrastructure solutions?

What is an anti-pattern?  It is a form of common practice that is implemented often with good intentions but which causes more harm than good.

By formally describing repeated mistakes, one can recognize the forces that lead to their repetition and learn how others have refactored themselves out of these broken patterns.

Note: anti-patterns formally require a definition of the bad practice with a matching solution.  This post is step 1: the bad practice

The existence of VDI anti-patterns don’t mean that VDI is a bad thing, but that bad things can happen; bad things that that repeat themselves in all of the solutions, no matter what size, which technology components, or business vertical.

VDI has been around for years, I first came across it in 2004, but I think it is about to come of age.  There are better technical solutions to old problems (better brokers, better protocols), and now it has been around for a few years people are also starting to iron out the operational wrinkles.

These operational wrinkles are seriously damaging to VDI because they directly impact the end user experience: and anyone serious about VDI will know that end-user experience is the #1 key performance indicator.  If you’ve never considered why an ESX %READY value is important to an end-user (what the hell as some obscure esxtop value got to do with Excel?): then you might be at risk of one or more of the VDI anti-patterns.

I think there are at least five anti-patterns when it comes to VDI:

1. Liberal use of the Somebody Else’s Problem (SEP) field.
2. Indifferent business case
3. VDI changes the desktop lifecycle
4. Virtual Desktops are NOT Virtual Servers.
5. Nobody owns VDI.

Failure to address these might mean VDI doesn’t get off the ground.  Worse still, failure to address, or attempt to paper over the cracks, and you can expect a degredation in the users’ ability to do business: and ask yourself, how happy and tolerant are you when your desktop isn’t working?

We need to avoid these anti-patterns because they feed IT Shriekometer, AND NOBODY LIKES SHRIEKING!

1. Somebody Else’s Problem field

Have you noticed that the top talkers around VDI are architects and technologists, usually vendors?  Pen in hand, whiteboard at the ready, they can regale you for hours, if not days, about the thin-client, broker, virtualization, storage, network, protocol, persistent/non-persistent desktop combinations.

These folks don’t always care about the big question of “How are we going to run this thing?”, or at least make it invisible by pretending that it’s Somebody Else’s Problem.

It is strange that more weight is not given to operations because the operational cost and complexity far outweighs the initial engineering of the solution.  If you think that it’s expensive to buy VMware View, then you will be frightened rigid by the operational expenditure required to operate a poor quality solution.  Unplanned work, in the form of desktops not working, for example, means resources that could be adding value are instead fighting fires.  It means lost business.  It means lost reputation.  Add all of those up, and the cost of VMware View is minuscule by comparison.

Building an operationally effective, efficient and governed VDI solution, from end-to-end for all teams and all components, should be paramount because it’s a critical part of all important end-user experience.

2. Indifferent business case

VDI is more expensive than physical desktops if you only cost the simple capital expenditure and ignore the raft of other benefits.  You can buy desktops for a few hundred dollars, whereas the infrastructure for VDI is considerably more.

The big benefits of VDI are all operational, here’s  quick selection:

• Decreased costs by reducing “IT floor walkers”.
• Increased service availability by using resilient infrastructure and automated disaster recovery for business continuity procedures.
• Increase service quality by making desktops available to the user wherever they are, online anywhere, offline anywhere (with VMware View checkout).
• Avoiding security compliance breaches because you can’t leave your desktop on the London Tube.

All of the above have monetary values that should be in any VDI business case.  The rest of the benefits are listed all over the web in the many cases studies, but have you tried to put hard figures on them in a business case, that can be defended in front of the CIO, COO, CFO?  It’s not easy, but that doesn’t mean it can’t or shouldn’t be attempted.

Intriguingly,  most common business driver I’ve seen for VDI has NOT been around the financials.  It has been some environmental driver that only VDI could solve: most often, in the recent economic times, this means office consolidation and company mergers.

3. VDI changes the desktop lifecycle

When you separate the OS from the hardware, many great things are possible:  no longer does your OS have the same depreciation and lifetime of the hardware it sits on.

Now your virtual desktop can live forever because virtualization allows it to move onto newer and newer hardware, and it never knows.

But when you do want to kill them off, The decommission process is now simpler: archive is now possible, delete is much easier – especially for costly compliance where old hardware needs to be specially destroyed.

When you go one step further and separate the applications from the OS, like with ThinApp, then you can get away from the old, clunky and complicated methods of installing application layers on boot, customized for each user.

This all sounds fantastic, until you recognize that the desktop team, and the users, are going to have to evolve their practices: applying the old desktop practices to virtual desktops is a recipe for disaster.  Running AV and SMS procedures simultaneously on thousands of desktops doesn’t work and WILL cause an outage.  Better to know this before you go live.

4. Virtual Desktops are not Virtual Servers

I was once in a meeting where someone else said “virtual desktops are just like virtual machines, so we can P2V all your users from…” I can’t remember what else he said, it didn’t really matter once my Nonsense Filter had kicked in.

Virtual desktops and virtual servers could not be more different whether you look at them from an architectural or operational view point.  Here’s just some favourite differences:

• A server typically runs one application in a predictable manner, requiring little administrator maintenance in a mature operational environment.  A desktop runs many applications, requiring user and central technical maintenance regularly.
• A server is part of a largely static architectural configuration, such as it’s place and neighbours in the network.  Desktops can move around the organization, including outside of it, and it’s configuration can change regularly (new applications).
• Servers are owned by the data center team.  Desktops are owned by the desktop team.  They both use different change, problem and incident procedures, including a different help desk and 1st line support.  Who you gonna call?

Virtual desktops are not just NOT virtual servers, they are also NOT desktops.  They are a new, evolved breed of computing unit, deserving of their own technology and operational approach.  This means change, but don’t confuse change with risk.  Doing nothing also means risk.

5. Nobody owns VDI

Following on from the server vs. desktop contrast, if you look at any enterprise VDI solution you will find that the technology components span multiple silos.  Each of these silos has it’s own operational procedures, priorities and policies.  Think desktops, servers, storage, network to name but a few.

It is uncommon to find one operational entity that is “the throat to choke” when VDI goes bad.  One operational entity that can:

• immediately tell you the capacity status of VDI as a whole
• measure the impact on end users, when an infrastructure incident is raised
• pinpoint where the problem is in the system, when an end user incident is raised

Here’s a diagram that shows common VDI components and how typically owns them, though your mileage may vary.  Who should own the Connection Managers (might be load balancers)?  Who owns the Connection Brokers (Desktop or VMware team)?  Who manages the Thin Client Device Manager (Desktop or Windows team)?
(click to open original)

This doesn’t mean re-organizing the silos.  Most organizations have a service group, usually with the incident, problem and change management teams in them.  This group is an overlay to the rest of the org.  There is no reason that this model cannot be evolved to create a service-specific team.  More on that later

Summary

I love VDI, I really do.  I’ve heard customers talk glowingly about the freedom they have with a virtual desktop, moving around their organization around the country and working from home, they log straight in to the same desktop and this increases their productivity and quality of life.

It’s not without its problems, though, and IMHO these are mostly operational – which is probably because little weight is given to these during the development of the solution.

VDI is maturing, especially the technology parts, but as usual the operational stuff is lagging behind and large enterprises are having to learn by mistakes.  I know that large customers commiserate and complain to each other about the state of VDI, and it’s not all about the technology: they want a better operational approach.

Related posts:

1. Desktops R Us
2. Five nines availability for VDI: no way!
3. Does your Desktop Service Strategy look a bit like this?
4. VDI and The Missing Art of End User Migration