In last week's column, I wrote that there's a difference between "local" and "offline" VDI. I stressed that even though you might have a connection, it might still make sense to run a virtual desktop locally on the client device (perhaps in a virtual machine) instead of connecting to a data center-hosted desktop via a remoting protocol like RDP.
That article spawned a lot of conversation and got me thinking about another point worth considering: Many people claim that in the future, bandwidth will be ubiquitous. When that happens, they believe, this whole offline use case won't exist, since users will never be offline! Personally, I think that's hogwash. Local virtual desktop infrastructure (VDI) has a valid role to play today, and it will have a valid role to play in the future.
When people suggest that ubiquitous bandwidth means users will never be offline, in the context of desktop virtualization, they're really saying that everyone can use VDI. Everyone's desktops can run in a data center because users will be able to access them from anywhere, and we won't have to worry about client-based solutions or local VMs.
The problem with this view is that desktop delivery solutions should seamlessly integrate into users' lives without forcing users to change how they work, and VDI—ubiquitous bandwidth or not—changes that.
For example, most laptop users today don't ever turn off their laptops. Users carry their laptops with them, and whenever they need to use them, they just open the lid and authenticate, and in about five seconds, their applications are right where they left them. They can pop in, quickly check something and close the lid again all in less than 30 seconds.
Some VDI-happy CIOs might think, "Hey, bandwidth is ubiquitous enough now that we can use VDI for everyone. We'll just give all of our users 3G cards and run their desktops in the data center!" But this setup doesn'tbout the connection process. A user flips open his laptop and authenticates. Then he needs to navigate to the 3G card software and wait for it to find a signal and initialize. The user clicks "connect" and waits. Then he launches the virtual private network client (or SSL-VPN) and authenticate there. The user then has to wait for the client-side security scan and hope there are no updates. The Web browser must launch and authenticate to the connection broker. Then the user has to click on his desktop and wait to be connected and to establish a secure session. Finally, the user has to wait for the desktop to pop up before he can actually do some work.
The complexity of this exact process varies depending on which products you're using, but the overall concept is the same: The desktop "resume" that takes five seconds with traditional desktops takes one or two minutes with VDI. Think about how many times a day you open and close your laptop's lid. Would you be happy with a desktop that only ran in the data center?
It's true that we will have ubiquitous bandwidth at some point soon. But even when that happens, we'll still have plenty of reasons to run desktops locally on our client devices (And remember, you can always run a VM on your client if you still want the benefits of virtualization!).
ABOUT THE AUTHOR
Brian Madden is an independent industry analyst and blogger, known throughout the world as an opinionated, supertechnical desktop virtualization expert. He has written several books and more than 1,000 articles about desktop and application virtualization. Madden's blog, BrianMadden.com, receives millions of visitors per year and is a leading source for conversation, debate and discourse about the application and desktop virtualization industry. He is also the creator of BriForum, the premier independent application delivery technical conference.
This was first published in December 2010