What Will it Take for VDI to Go Mainstream?
What Will it Take for VDI to Go Mainstream?
By Martin Ingram
published: Friday, June 26 2009


AppSense_20090626.jpgWhat Will it Take for VDI to Go Mainstream? - By Martin Ingram
 

The IT industry readily adopts new terms and technologies, frequently well ahead of those technologies being well understood, available, and in use in the real world.  Such has been the case with VDI.  The term was coined way back in 2005, yet we are only now approaching a stage where it can become a viable platform for broad-based implementation. That is not to say there have not been successful VDI deployments so far, there have been many, but they have been mostly implemented for only a small section of a business's employees.

 

So, why haven't successful small VDI implementations lead naturally to wider-scale adoption, and what needs to change so that they can?

 

I am going to start by looking at the characteristics of the early implementations and why they were a success.  From there I will look at newer implementations that are taking a very different technological path to make desktop virtualization relevant for a broader proportion of the corporate population.

 

Early VDI Implementations

Whoever first thought of hosting client operating systems on hypervisors in the datacenter and delivering only display data to end users is lost in the mysteries of time. I know at least three groups or individuals that would lay claim to that crown.  The solutions constructed in the early days were built from the available technologies at the time, but gradually a pattern emerged amongst those early implementations: Multiple virtual machines (VMs), each with a copy of Windows XP and the standard corporate applications, would be created and then allocated to users as they migrated to the system. The VM containing the image would then become the ‘property' of the user and they would access this same image every time they logged on to the system. Implementations varied in the management sophistication around the solution; some using brokers, others doing without, etc., but the basic pattern was used over and over again at organizations around the world.

 

Intriguingly the reasons for deploying VDI were very similar among organizations in these early implementations. They were to address off-shore developers and used two principal justifications:

  1. It would be cheaper and more effective to support these users centrally rather than having to provide desk-side support.
  2. The use of a display protocol provided better protection for corporate data because data did not have to leave the data center.


This makes good sense - The use of a persistent but easily replaced VM image fits well with the type of use that developers typically make of their machines. Other early implementations accommodated geographically-dispersed users, with similar justifications.

 

In both of the above cases, the reduction in support costs came from centralizing the PC image and avoiding the need to have a skilled person available to go desk-side with these remote users. Instead, all image maintenance could be done centrally, albeit still on a per-image/desktop scale. Users' PCs were replaced with a thin client device, which does not require maintenance beyond the ability to replace the unit on hardware failure, and which can be entrusted to less technically skilled employees. This reduction in remote desk-side support cost more than covered the increased cost associated with providing a thin client device and a share of a server in the datacenter.

 

The security justification mentioned above is one that is frequently cited but in practice most organizations cannot justify expenditure to reduce the risk of infrequent, if expensive, events.

 

These two scenarios represent the vast majority of the successful early implementations but the crucial point to note is, the business justification in both cases is based on a premise that does not apply to the majority of users in the organization - most users work in larger groups. But we still have the problem that PCs are widely recognized to be expensive to manage. As Gartner Group notes, it typically costs several times the initial capital cost to manage a desktop through its lifecycle. Consequently, organizations that implemented one of these early VDI implementations are now looking for ways to take VDI to a broader set of users. In order to do so, the industry is going to have to make a substantial change in the way it manages virtual desktops. In order to understand the changes that need to be made, we first need to look at what makes PCs difficult to manage, and why they frequently do not deliver the quality of service for users we want.

 

Essentially, the problems in managing PCs stem from the ‘personal' nature of the PC.  While we may deploy a gold image to new machines during hardware refresh, and seek to keep them up to date with software deployment systems, the reality is that once users start using a machine, they quickly make the machine unique. Either through changes to configuration or the introduction of applications and plug-ins, the machine strays away from the gold image. This limits IT's ability to manage the machine because, when a user reports a problem, it is difficult to know whether the cause is a real problem, a failure in application deployment or, a user-introduced fault. Consequently, much time is wasted trying to understand where the fault lies and, frequently, if a cause cannot be quickly located, the machine will be re-imaged. This wastes IT time and disrupts users from working. Additionally most users' machines are defective in some way but users wait for major problems before calling the help desk and hence the quality of service of typical machines is low. Early VDI deployments did not seek to challenge this basic problem with PCs - they just centralize the images. If we keep the PC image identical for all users and also keep it up to date, then the problems of ‘uniqueness' go away. This has been tried in the past and is referred to as PC lockdown - users are prevented from changing anything on the machine and are only allowed to run a limited set of authorized applications. However, the loss of user flexibility and the cultural shift in taking away users' control over their work environment has severely limited the success of lockdown.