The point of VDI and some options
- Cost. Different organizations will weigh the cost driver differently. For example, one organization may place a significant premium on the cost driver and less of a premium on the user experience. Alternatively, some organizations want to deploy VDI solutions solely to save money – the other factors are not as important.
- Manageability. For organizations that have poorly managed desktop environments, VDI might seem like a panacea. Everything is consistent; desktops are built and destroyed on demand; malware becomes a thing of the past as the new process takes hold. Obviously, it’s not all quite this rosy, but the situation is certainly better than an unmanaged environment.
- Mobility. A VDI solution brings with it new mobility opportunities as users attach to the same desktop wherever they happen to be. Some VDI solutions also include offline desktop capability whereby a mobile user can carry a VDI-provisioned desktop with him and use it without connecting to a network.
- User experience. This is the area that is most difficult to replicate. A regular desktop environment is a versatile and powerful tool that can run pretty much anything and do it well. VDI-based terminals don’t always enjoy this same versatility as evidenced by the plethora of multimedia and USB enhancement protocols available on the market. From PCoIP to HDX to TCX to, well, many more, there are a ton of ways to make the VDI experience more desktop-like. For some organizations, this is a key factor in the VDI rollout, but it does make it a more expensive proposition as additional licenses and more powerful devices need to be considered.
- Bring your own device. There are a lot of companies exploring bring your own device (BYOD) initiatives as a way to empower employees and lower costs. VDI solutions are a perfect enabler for these kinds of initiatives since a corporate-provisioned desktop can be used by any device.
Now, let’s take a step back and consider what we’re trying to accomplish with the various desktop and VDI initiatives that we’re undertaking.
It’s all about the apps
During a presentation I was coordinating last week on various desktop delivery methods, one of the participants said it best: “It’s not about the desktop. It’s all about the apps.” That comment gave me pause and caused me to change my thinking a bit about some of my own initiatives.
When it comes down to it, that’s what matters. Who cares which operating system is being pushed to a user? Heck, who cares if a user is even using a supported operating system? The goal is to make sure that users have access to the applications that they need to do their jobs. As long as that goal is met, the rest isn’t all that important.
VDI in the slow lane
I’ve been working with a VDI project for quite some time but continue to have some concerns about the technology. These concerns revolve mostly around cost. Frankly, to deploy a VDI solution that closely replicates the expected user experience, the costs can add up, but there are some ways to mitigate this. Obviously, there are drawbacks to every decision. Here are some of my thoughts:
Save money by reusing existing hardware. Existing hardware can be reused which negates the need to buy new terminals, which can be more expensive than one would think. This extends the life of existing hardware while still being able to deploy the new solution. This direction still has some drawbacks, though. As I mentioned before, you have to balance your objectives and make decisions around what you need.
- Lost energy savings. When existing hardware – usually older desktops – is reused, organizations don’t enjoy hardware with lower energy costs.
- Inability to use some features. Some VDI multimedia acceleration methods – notably Teradici’s PCoIP protocol – require specialized processors. You will need to rely on other third party tools to replicate the full desktop experience.
- Continued need to maintain old hardware. Although this approach will save some money, it also means that there could be a higher failure rate due to use of old hardware. On the plus side, it should be easier to swap out the hardware in the case of failure since no user data will be stored client side and all apps reside on the server.
- Continued need to patch and manage desktop-based clients. This is probably the biggest downside – moving ahead with this option will require IT to manage the VDI-hosted system and maintain patch processes for desktop clients running full operating systems.
Use less expensive terminals. Not every VDI terminal uses Teradici’s processors (in fact, PCoIP is just one of many, many options out there) for improved multimedia performance. You can make a judgment call to use less expensive terminals (the best price I’ve seen for a PCoIP-supporting terminal is well over $350 per unit) and maybe choose another acceleration technology.
- Third party acceleration tools. If you decide that you need multimedia acceleration, you’ll need to procure third party tools to do so. This will add some additional cost and overhead to the solution.
Traditional server-based computing
When I use the phrase “traditional server-based computing” I’m thinking of such companies as Citrix and products such as Terminal Services, now named Remote Desktop Services. These terminals convert a Windows server from an application-oriented system to a user-serving powerhouse. With newer features, such as RemoteApp, Remote Desktop Services might be just what you need to make sure that your users enjoy wide access to your programs. Here are some other things to keep in mind when considering Remote Desktop Services:
- It’s a shared medium. Whereas a VDI-provisioned desktop generally provides a user with a dedicated desktop-focused operating system with local installations for necessary applications, Remote Desktop Services users are all sharing the same hardware as well as the same software. While this technique improves overall density – RDS supports more users than VDI – it also adds new challenges.
o You pretty much have to forgo administrative rights. Allowing users using Remote Desktop Services to also have administrative rights is a recipe for disaster. A single user’s actions can have a devastating impact on all of the other users of the system.
o Some applications do not support a shared environment. There are some applications that don’t work well in a shared environment such as the ones provided by RDS. With VDI, applications are running in dedicated instances, so these problems go away.
- You enjoy higher user density. RDS allows you to have higher levels of density than you get with VDI. Why? Traditional VDI-provisioned desktops require that you publish both operating systems and applications for each and every virtual machine. With that comes a lot of duplication as many instances of Windows, for example, are running simultaneously. With RDS, there is a single copy of the operating system running.
Some third party providers, such as nComputing, leverage Remote Desktop Services to enable their solutions. As a side note, nComputing also works using desktop-based Windows systems, but that’s an entirely different discussion. nComputing’s Ethernet-based devices and the associated software add drivers and software to the Remote Desktop Server than improve, among other things, USB redirection capabilities and multimedia display performance. This can help to bring an RDS implementation, from a performance perspective, more in line with the traditional desktop model.
RemoteApp and similar technologies
Keep in mind that it is not the business goal of desktop computing to deploy an operating system; the overall business goal of desktop computing is to make sure users have access to the applications they need in order to do their jobs. The underlying operating system – usually Windows – simply facilitates this business need. So, we move on to identifying ways that we can deliver applications to users without delivering to them a complete server-based or VDI-based desktop.
A feature in Remote Desktop Services called RemoteApp helps to enable this capability. RemoteApp allows IT to distribute applications to users. RemoteApp leverages Remote Desktop Services. Applications are actually installed on the RDS host but, when executed, appear within the context of the local machine.
Obviously, like all technologies, there are pros and cons to this approach:
- You still need RDS licenses. Even though you’re not pushing a complete desktop, you still need RDS/TS licenses to use RemoteApp. As such, there may not be much in the way of cost savings from a software perspective.
- You might be able to extend the life of older hardware. If you’ve got older hardware out there, this might be a perfect way to maintain your current environment while providing it with a bit more horsepower. For those applications that are burdensome from a processing perspective, you can publish them via RemoteApp which allows the processing to take place on a beefy server while the user interacts with the application via a transparent remote desktop connection.
- It’s easy to make applications available remotely. When combined with RDS Web Access, Microsoft makes it a breeze to make applications available to users connecting from the Internet from other devices. Simply browse to the RDS Web Access server and you see a list of published applications. Obviously, you can control if and how this feature is used, but it does simplify the process of making applications available to users on the road.
- If not used consistently, adds complexity to the environment. A full RDS deployment that supports RemoteApp adds an additional service that IT needs to manage and also adds a deployment step when a new application is rolled out.
In a future article, I will discuss various application virtualization options. Here, I limited the focus to application presentation.
I believe that almost every environment will benefit from a combination of the aforementioned technologies. Where I work, we’re actively considering the use of nComputing’s L300 model access devices. Our initial testing has gone well and we’re cautiously optimistic that additional testing will reinforce this experience. However, we’re also looking at RemoteApp on a per-application basis. For example, our ERP software can be a bear to install and configure and there are frequent upgrades. RemoteApp would take the pain away by allowing us to install and configure once and then easily deploy via an RDP or MSI file to our campus desktops.
In other words, the endeavor is not a one-size-fits-all affair at all. Only through an appropriate mix of solutions will organizations meet their cost containment and operational improvement goals.