In my post, Contrarian View on VDI I describe some of the challenges surrounding a virtual desktop project.

In Part 2, I set forth some expectations for organizations looking to take on a virtual desk too project.

In this final post on the topic, I hope to help provide some guidance on how to avoid some common traps that add cost and time to a VDI project without adding real value.

Trap #1 – The Proof of Concept or Pilot

DON’T DO IT!!!

Do I have your attention yet? Good.

This is probably my biggest pet peeve. Too many companies or organizations jump right into playing with the technology without really understanding the impact to the organization or the budget. This is true, of course, for more than just VDI, but it seems to be especially problematic in this space. If you have read Parts 1 & 2, then hopefully you will see there is plenty of work to do on justifying the project long before you ever lay your hands on the technology.

Is there a time for playing with the technology, and having a bake-off, and running a Proof of Concept or pilot. Of course there is, but please don’t waste anyone’s time by playing with it until you are sure there is a place for it in your organization.

Trap #2 – Thin Clients

This is probably my biggest pet peeve. If you insist on deploying thin clients as part of the initial project, all you are going to do is increase the cost, complexity, and time, and pain associated with the project. The thin-client vendors have done an excellent job convincing the industry that you can save money with their very clever devices. They avoid the nasty conversation where they tell you first you have to dump a whole buck of compute power into the Datacenter, unless you go with high-end devices running embedded Windows, but guess what? Those can cost more than a PC!

Certainly, thin clients can save your company on power (since they draw so much less than a full desktop), and they do offer savings other ways. Hyper-standardization on a device with no moving parts and a mean time to failure that is at least 3x as long as a desktop offers opportunities for massive savings in operational efficiency over the long term. But you still need to get some servers in the Datacenter.

Do yourself a favor, and hold on to your desktops until they die. While they are serving out their remaining months and years, take the opportunity to figure out all the use cases for thin clients, and then you can pick the right one!

Trap #3 – Other Toys

The bit culprit here are monitors…. I have spoken to more than one customer that wants to give their users the warm fuzzes as part of their “thin client” project. They feel that if they are taking away the user desktop, they want the user to have a positive emotion related to the experience, and giving them a nice, bug, shiny, new monitor will fit the bill.

Do we want our users to have a positive experience? Of course we do! However, I take issue with calling it a “thin client project”- already I can see the priorities here are misguided. Similarly, any other device or peripheral that you intend to use as a’warm fuzzy’ for the user is once again going to increase the complexity and pain on the project.

If you want your users to have a good experience, give it to them by showing how much more reliable the solution is, how much more ubiquitous it is, how easy it is to work from home, and how well it performs.

Trap #4 – The Great Protocol Debate

RDP? ICA? HDX? And so on…

Your vendors and partners may try to suck you into this debate with a heady discussion of bandwidth per user, differential caching of pixels or bitmaps, progressive builds, and such. As a nerd, this is a very seductive discussion, but at the end of the day it is not really germane until you have performed a thorough desktop assessment, and established what your target use cases should / will be.

Most remote desktop protocols will deliver a decent enough experience for most task-based use cases over the Internet, when connected over broadband. If you fall into that bucket, then don’t worry about it, and focus on other aspects of the solutions that will bring greater value… Management, automation, and so on. If you have specific needs, then sure, get into the debate, but again- please don’t waste anyone’s time by engaging in the debate until you know your requirements.

Trap #5 – Choice of Disk

VMware, Citrix, EMC, NetApp, and others have all come up with some great technologies to reduce the capacity requirements for thousands of desktops, whether it is through clever manipulation of the virtual machine files (VMware linked clones or Citrix Provisioning Server), or through disk technologies (snapshots). But don’t ever confuse capacity with IOPS… Too many customers try to start with a small SATA array (oh, it’s just desktops… Can’t be that bad, can it?). YES IT CAN!

I drill into the basics of disk type and architecture in another post – Virtual Desktops and Disk Architecture – the Basics. Briefly put, however, virtualized desktops are workloads that sit on shared storage like any other virtual machine, and they have I/O requirements, just like any other virtual machine. As with any other workload, requirements could probably be serviced by many different types of disk, over FC, iSCSI, of NFS. Whatever you do, please take the time to talk to your storage vendor about design, and PLEASE follow their recommendations.

To sum it all up…

Get sponsorship, understand your use case, get some help, design a robust solution, and don’t get distracted.

– Posted using BlogPress…