The VDI Skeptics: VDI isn’t bad -- it’s just heavyweight

The VDI Skeptics say virtual desktop infrastructure isn’t a bad idea, but today’s application delivery model is heavyweight. Consider lightweight options first.

The VDI Skeptics firmly believe that business comes first, not technology. While they feel that virtual desktops are undeniably cool, they don’t necessarily believe that they offer true value to a lot of the businesses that pursue them. In this series of articles, the skeptics outline their arguments for and against various VDI technologies, helping you focus on what your business actually needs -- not on what vendors want to sell.

Google the phrase “complexity is the enemy of,” and you’ll see that complexity doesn’t mix well with ... anything. So it stands to reason that a less complex IT architecture always trumps a more complex one. Yet that’s not the case with virtual desktop infrastructure (VDI).

In our first VDI Skeptics column, we introduced you to a technical analysis that our company, Concentrated Technology, completed on VDI architectures. We deconstructed each of the components needed to build the most common desktop virtualization architecture.

We focused on capabilities, not products, and found 10 layers of integration and 19 components necessary to construct a functional VDI architecture (see Figure 1).

Figure 1: The Concentrated Technology VDI model.

Greg presented a summary of these findings at the Windows Connections conference in Las Vegas this October in a session titled "VDI, RDS, MED-V and App-V: Making the Right Decisions in Deploying Applications." There, he showed how the model was constructed using 30 slides.

Today, VDI is commonly accepted, but it's a heavyweight solution to application-delivery problems. As Figure 1 shows, a VDI architecture requires a lot of moving parts and integration. Not all of those pieces are available through a single product or even a single vendor, which further complicates the design.

Greg also suggested that the application-delivery problem might be solved with lighter alternatives. Since it was a Windows conference, the presentation focused on Microsoft-centric app-delivery alternatives, but you could easily find others.

VDI isn’t bad; it's heavyweight
Our first few VDI Skeptics articles received an overwhelming response. Many respondents suggested that our skepticism was misguided, saying those with fully realized VDI solutions enjoy the ability to deliver applications and desktops to users anywhere with a network connection. An equal and opposite group of respondents thanked us for suggesting caution before jumping into desktop virtualization with both feet.

But the one sentence from our first VDI Skeptics article that struck a chord with everyone was this: “Virtual desktop infrastructure, or VDI, is a bad idea.”

In thinking about those three words, "a bad idea," perhaps “bad” isn’t the most-appropriate word. It suggests there are no solutions of value, no architectures that improve the user experience while reducing cost or containing risk. In retrospect, “bad” is a useful word for sensational headlines, but it doesn’t give the technology the credit it deserves.

So, we’d like to adjust that original assertion. We, the VDI Skeptics, don’t necessarily believe that VDI is a bad idea. Instead, today’s industry-accepted VDI concept is a heavyweight solution.

Our definition of heavyweight can be drawn from our first article, where we said VDI is “full of expensive components, complicated interconnections, layers that haven’t fully been realized, and a multivendor marketing machine that places sexiness over true business value. VDI represents our industry’s red herring du jour.”

Figure 1 represents this complexity in glaring color, showing the 10 separate layers in the most common VDI model. Those layers start at the top with endpoints and endpoint management, then travel down through desktop advertisement, transport protocol and desktop orchestration layers before arriving at anything resembling a virtual machine (VM). Continuing through that VM layer are management requirements for operating system, application and user workspace provisioning. All of these sit on top of the virtualization layer itself, which includes the hypervisor, hardware, storage and the management pieces in between.

You might feel that these 10 layers and 19 components require an overwhelming amount of integration. That feeling grows even stronger when VDI’s 19 pieces are compared with the far simpler integrations required to construct classic Remote Desktop Services (RDS). Figure 2 shows a comparative graphic for RDS, which requires far fewer dependencies.

Figure 2: The Concentrated Technology RDS model.

Ignore vendor labels and start light

In the end, users don’t care how their applications and data are delivered, as long as they’re always available, completely secure and relatively transparent to their daily business processes. If IT can meet those requirements, then we’re free to construct the solution in whatever way works best for us and our budgets.

VDI offers many options for the delivery of apps and data, and it’s important to have a firm grasp of these delivery mechanisms before choosing one. Lightweight alternatives such as presentation virtualization, application virtualization and even client virtualization could meet users' needs with less complexity for IT than heavyweight VDI.

Start by eliminating anything resembling a product or feature name from your application-delivery strategy. Strip away the marketing, the products and even the feature sets from each vendor as you analyze your requirements. 

Begin with lightweight approaches that accomplish tasks using simple infrastructure and low levels of integration. As you analyze the capabilities of each approach, move down your list and rule out those that don’t work for you. You’ll locate a delivery model -- or a range of them -- that satisfies your organization's requirements, and that model might not be as heavyweight as you thought you needed.

Dig Deeper on Virtual desktop infrastructure and architecture

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.