The 20-layer VDI model

I’m not a VDI expert but I do know a little bit about it so I get a chance to talk to customers on the topic.  One of the things I share with them is how complex VDI really is and I wanted to share my thoughts with you in the hope that something good emerges out of the discussion.

First of all, I think of VDI as a service not a solution.  That service has customers and end-users, and it is comprised of technology layers like “Desktop” and “LAN” and it also should contain service elements such as “Monitoring” and “Availability”.

I jokingly call this the “20-layer VDI model” and it’s not a serious attempt at a reference model, it’s just for illustration.

On the left you have the teams who own the different layers.  Each layer is components like “product” or “process” or something, it doesn’t have to be a specific product.  At the top the service starts with end users, at the bottom you get the back end infrastructure and operations.

The main talking points about this model:

1. There may be fewer or more layers, but there are always many.  Many layers means complexity.  Many layers means many teams which means tribes which means communication challenges and an increased probability of the Somebody Else’s Problem field appearing along with a reduced Mean Time Between Cockup (MTBC).
2. Different end users have different requirements and therefore different routes through the layers where more than one option is available.  The same end user might use a different path (e.g. internal LAN vs. external WAN) depending on their location: will they get the same SLA?
3. Shared infrastructure is inherent in this model, and that means mature operations are critical.  The network teams are pretty good at this as they’ve been doing shared infrastructure for years and therefore have highly redundant and available systems and methods.  But it counts for nothing that the network team are 99.999% available if the broker is only available 80% of the time.
4. There is a tendency to ignore the layers you don’t understand or don’t control.  This is a common and fatal mistake, mostly perpetrated by vendors who specialize in a niche area.  You’ll see this where important, complex pieces are abstracted away into a “cloud” or a big box with “data center” written on it.  Somebody has to do the tough stuff, it doesn’t disappear.
5. An action at one layer can impact the behaviour of another layer, sometimes unintentionally, with catastrophic impact on the service.  SMS update to 1000 desktops bringing down the SAN?  No, surely that can’t happen…can it?

What I strongly advocate for VDI is the creation of a standalone VDI Service Team that is involved with VDI from strategic inception all the way through to operations.  They write the VDI PID/Charter.  They have budget that they spend on Technology Providers.  They own the governance, standards and metrics for the service.  Technology providers own the people, tools and technology of individual layers.  The VDI Service Team reports to the CIO, or equivalent.  They do things like measuring and reporting on availability and capacity.  They host the bride calls when a Sev 1 outage occurs.

One shocking finding that I come across consistently is the common VDI refrain “End user experience is #1 focus” is always technology focused (e.g. best protocol for bandwidth, latency, features etc) and never, ever IMHE focused on mature operations and “boring” stuff like Availability measuring, analysis and reporting.   If you can’t tell me the availability metrics for each component for each layer for each team and for the VDI service as a whole, then why waste time evaluating protocols for “great end user experience” when you don’t have control nor understanding of the service?

Well, that’s what I think anyway and that thinking is based on quite a bit of involvement in VDI projects and observations and analysis of countless more VDI projects.  Customers get it, especially the people who will be ultimately on the hook for VDI.  However, there are much better VDI experts than me out there and I’m curious to hear what they think…