What Will it Take for VDI to Go Mainstream?
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:
- It would be cheaper and more effective to support these users centrally rather than having to provide desk-side support.
- 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.
