The Desktop Virtualization Iceberg

Desktop Virtualization is not an easy undertaking. There – I’ve said it. “But,” you may say, “I take a copy of the desktops I have, I  run them on servers in the data-centre. Once that’s done, I don’t need to update those desktop devices; I can update the virtualized workspace instead far more quickly.  The desktops are running on server hardware so they will be more reliable. Eventually, someone may well offer to host these workspaces on some infrastructure out in The Cloud”.
“Really, how hard can it be?”
If you are steering your organisations desktop strategy you need to consider that what may seem like a straightforward undertaking can in fact be a much larger and complex task. As with with any obstacle, understanding the size of the problem early gives a greater chance of avoiding it.
Lets consider the hosted desktop iceberg – how complex can a VDI solution be?
With thanks to Ron Oglesby from Unidesk for the images, it is likely that you’ve considered that desktop virtualization is fundamentally this:

While such an architecture could work for a small organisation it gives very little benefit for your investment in migrating workspaces to the data-centre. There will be a significant sum expended in purchasing and installing server hardware to host the desktops; the migration exercise; the software to migrate and deliver those desktops and manage the entire environment. But, all you have done is move the desktops from the office to the data-centre. In fact, in some instances, the client device still needs to retain applications and their own operating system. While this architecture may be more secure the end result is often little different from managing individual desktops, and now you not only have to manage the desktops, you have to manage the servers hosting the desktops.
A well designed, reliable hosted desktop architecture that will scale effectively will appear more complex. When you sit down to plan that architecture, it is very likely there will be a number of components that you need which you did not originally consider. It is more likely that your final design will look more like this:

Reaping what you Sow
Your first thought might be, ‘this is more complex, its going to be expensive’. You’re right. The design needs planning. Your initial investment will be larger, yes. But, this architecture will better able to deliver a successful implementation and will more likely ensure that your users are more productive. Your investment in this architecture will generate a return far more quickly than with the first model, and is less likely to fail.  What are these components and why are they important?

• Client Management: the devices that present the hosted desktop will need to be maintained. This can range in complexity from managing a full operating system to managing a thin client – sometimes to the extent of not having an operating system on the end device at all. It is true to say that thin clients (TC) need less management than delivering traditional PCs/laptops, but then functionality available in a PC may not be delivered on a TC (e.g. off-line access, support for a locally installed applications, the ability to group them together and make a fort).
• Image/OS Management: To scale your environment, and respond to business change demand quickly you need to be able to update core desktop images quickly and effectively. It is not always possible to have a single image used by all devices. How will you accommodate test and development environments?  Different users have different needs, how will they be served?
• Application Management: How will you deploy new and updated applications to your desktops? Your goal is to have a method that allows you to create a stable environment but that doesn’t add complexity and delay to introduce new applications that the business needs and ensuring that the right users get the right apps to keep your license costs in check.
• Profile Management:how are user’s personal settings stored and delivered so that each time they access their workspace, they don’t spend 10 minutes setting the background and putting all of the right toolbars back in Excel and hunting for their browser favorites.
• Storage Footprint: all of this ‘stuff’ needs to be kept somewhere. That data store needs to be managed and maintained. Ideally, your architecture incorporates a way of minimising the amount of data needed (to reduce the amount of data to manage and maintain).

Does this mean we’re going to need a bigger boat?

The first diagram will shows VDI in its raw form – offering very little, potentially costing very much. VDI projects that have failed are likely to have this design. The second diagram is more complex because its architecture mirrors what it is that a desktop is: a thing of many parts.
Delivering a workspace for users to access applications and their data effectively is more than simply delivering a desktop. You need to manage the operating environment of the device itself; by separating applications you allow delivery of app across platforms and environment – speeding deliver time, by managing profiles you allow users to have consistent settings across devices, managing workspace OS you keep environment
This is why solutions such as Citrix XenDesktop, Quest vWorkspace, and VMware’s View are not simply “connection brokers”. The vendors acknowledge that a reliable solution has some complexity and offer functions to help. At the same time, there is a healthy third party market for services to compliment the core offerings these vendors have – because those built-in solutions can be improved or extended to work across platforms, or to scale for larger numbers of users, or even to add additional features.
Interestingly, using this architecture it is possible to remove the ‘desktop broker and VDI’ component and replace it with alternative solutions. In the first diagram everything needs to change together – each device managed individually. However, in the second diagram, if you are in a position where application, client device, operating system and profiles are managed independently, you can be far more flexible in delivering services to business in a consistent manner, with the  minimum of effort. In making use of standardization and automation to deliver to your business for VDI, those same tools can be used again for other platforms.  Delivering the different components not only assists in delivering a successful VDI solution,  but helps deliver a combination of solutions for your desktop strategy.
And finally, thanks again to Ron Oglesby for the two images.  Some would suggest I could have achieved the same thing by having the article simply showing the first image and saying “do your VDI not like this” and then showing the second and saying “but like this” – but then I’d have had all these boat analogies beached and looking washed-up, and no-one wants that.