Often, when the decibel level of a conventional wisdom reaches a feverish pitch, it can be wise to seek the opposite of what the convention suggests. Examples of this wisdom happen all the time in our daily lives. When the masses refinanced into 3‐ or 5‐year ARMs, the smart ones held their 30‐year fixed mortgages. Investors follow similar behaviors. The irrationally exuberant moved conservative‐but‐reliable securities into high‐risk tech stocks and learned how fast the bubble bursts when "everyone else is doing it too."
In the past few years, those same behaviors have been infiltrating our industry. For us, the topic isn't mortgages or investments. Rather, it's the approaches we use in delivering desktops to users.
"VDI is the answer, and the answer is VDI!" is a common theme you'll hear as you attend IT conferences or read industry magazines. Yet the exuberance that surrounds VDI technology belies the fact that VDI is but one approach to desktop delivery. VDI is also only one of many options to benefit from desktop virtualization. Unfortunately, as too many find out far too late, VDI might not necessarily be the solution to your users' needs.
If this series' title confuses you, don't fret. You're not alone. Thanks in part to an impressive volume from marketers and aficionados alike, VDI has quickly elevated from niche topic to "something you absolutely must do." Although VDI technology is undeniably exciting, VDI and desktop virtualization aren't necessarily the same thing. In reality, VDI is but one of many ways in which desktops can be virtualized.
VDI represents an approach to desktop delivery, just like manually installing a user's desktop via DVD media. VDI's primary difference stems from its centralization. VDI deployments centralize desktops into the data center, enabling IT to act as a service provider. From this location, IT gains operational efficiencies over the traditional physical desktop delivery approach, such as the ability to manage just a single copy of Windows, having all others operate as clones from that template original.
Yet many who are considering VDI don't realize that it presents IT gains as well as losses. Users tend to lose in the deal as well. VDI's approach functions exceptionally well for task workers who consume static application sets. It fits lab environments that require rapid deployment and turnaround. It can also be a perfect solution for users with light application sets who never leave the confines of their local high‐speed LAN. VDI's undeniable charisma, however, reveals its true limitations the moment those workers move outside the brick‐and‐mortar. Attempt to push Adobe Flash, video, or voice over WANs, and users quickly discover the use cases where VDI fails to meet their needs. Highlighting this contrast is the goal of this series. In it, we'll explore what desktop virtualization really aims to accomplish. You'll also learn about virtualization approaches that may provide a better fit than VDI for your situation. Focusing first on the needs of the user and second on the improvements offered by virtualization to IT automation, you'll see the big failures traditional VDI introduces to the social contract between users and IT. On this journey, you'll come to understand how one particular approach—hybrid desktop virtualization—combines the best of the others to merge IT's centralization desires with users' real‐world requirements.
The guiding notion behind desktop virtualization is IT's desire to optimize asset management. Look back not that far in the past and you'll find all kinds of terrifically in effective examples of our early management practices:
Although automation toolsets indeed brought some centralized control to these activities, implementing the toolsets began an industry obsession with strategies that favor control above all else. At fault is the very real human nature to seek solutions that make one's life easier. Nearly any IT administrator will tell you, "Everything would be much easier if we could better lock down our desktops."
Yet although control and lock down absolutely fit IT's goal of making their job easier, this heavy‐handed approach hinders the users' experience. Ever worked in a fanatically‐lockeddown environment where every personalization element is defined for you, every application is nailed down tight, and every data access is check pointed by multiple security controls? The experience isn't pleasant. If this environment embodies your administrative mindset, take off your Domain Admin gloves some day and try working as a regular user for a while. You won't like it either.
That's why the emerging IT conventional wisdom recognizes that a single‐minded control focus will never achieve desired goals. The reality is that users will always find a way around. Increase password complexity, and users will write them down on sticky notes. Take away their personalization, and they'll construct elaborate business justifications why personalization must remain. Move their desktop into the data center, and they'll just switch to their (far less trustworthy) home laptop to finish their work.
All this said, centralization is important for management, security, and simply keeping people connected in appropriate ways. For the right desktop virtualization for your environment, you need to find the best balance of centralized management and control while maintaining the best possible user experience and mobility.
If VDI is only one approach to desktop virtualization, what really is this superset? What are the different ways in which desktops can be virtualized, and why? The most commonlyknown approaches typically arrive in one of two forms: serverbased desktop virtualization or clientbased desktop virtualization.
Server‐based desktop virtualization represents the traditional VDI concept. With it, desktop processing executes inside the data center in a pool of specially‐created virtual machines. Users access those virtual machines using one of many remote protocols (ICA, RDP, PCoIP, and so on). Most solutions leverage pools of desktop clones that are provisioned to users at the point of login. Applications, configurations, and personality are delivered on‐demand during the provisioning process.
Most server‐based desktop virtualization solutions are forced into this pooled architecture due to the high cost of storage and IT's desire for centralized control. Keeping things running smoothly requires limiting personality elements and the set of applications delivered to the provisioned desktop. With shared resources, a user running heavyweight applications won't have a good experience when inappropriately collocated with others on a virtual host. Server‐based desktop virtualization also has the oft‐overlooked effect of relocating large quantities of data away from inexpensive desktop storage and onto expensive SAN storage. It's the same data; you just need more dollars to keep it around.
Client‐based desktop virtualization relocates the desktop's processing back to the desktop. The user still interfaces with a virtual machine, but that virtual machine is stored locally on the user's physical computer. There, the local processors, memory, storage, and networking are used in processing the virtual machine's activities.
The biggest user experience benefit of client‐based desktop virtualization is in eliminating the reliance on a remote protocol. The computer resides locally, so the OS instance can follow the user as they move around. Taking a laptop outside the confines of the LAN means still having access to applications and (locally‐copied) data without the need to first find a fast‐enough network connection. It also means being able to horizontally scale the environment without resorting to comparatively‐expensive server‐class equipment. With client‐based desktop virtualization, scaling out means buying a few more desktops or laptops. That's great for the pocketbook.
Yet this approach isn't without intrinsic problems as well. Most client virtualization requires some form of hypervisor in order to do its job. These hypervisors tend to come in one of two types: installed directly to the computer's hardware or installed into another OS. Whereas the hypervisor has been such a boon to optimizing servers, using it at the desktop doesn't bring an immediate win. In the first hypervisor case, the directly‐installed (Type‐1) hypervisor must be aware of, or able to become aware of, every single device ever connected to or inside a computer. That's millions of drivers, which represents a project so enormous that any of today's directly‐installed hypervisor solutions suffer under the weight of a severely limited hardware compatibility list.
The second case isn't much better. Installed on top of an existing OS, the second (Type‐2) hypervisor architecture eliminates the driver problem but has the effect of doubling your number of systems under management. The first is the host OS, and the second is the virtual machine. That situation is not more efficient, it's less so.
As you can see, desktop virtualization at both the server and client side arrive with their own set of detractors. The server‐side case improves centralization but at the cost of flexibility and mobility. The client‐side case reverses that equation. Arguably, with only these two options at one's disposal, it is easy to see why VDI remains a viable solution: the cons of clientside option don't outweigh the pros of serverside setup.
But what if some mechanism existed that could hybridize the best parts of both approaches while eliminating their cons. Such a solution might actually find that perfect balance between IT's centralization goals and users' need for flexibility. That solution can exist, if architected with the previously mentioned pro/con list as its requirement specification. One possibility is hybrid desktop virtualization, an explanation of which you'll find in the third article.
But before we get there, we need to further nail down the exact reasons our existing VDI technologies fail us. That understanding will help you realize why something fundamentally different is in fact superior. The next article in this series provides a review of VDI's big failures.