BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
As virtual and remote desktops -- not to mention mobile devices -- start to pervade our environments, admins are finding new ways to deliver applications to end users. One method to consider is application virtualization.
Application virtualization includes remote applications and streamed applications. Remote apps run on a remote server rather than on a client device. With application streaming, apps are executed on the local computer but only certain components are downloaded, making it possible to function without a network connection.
Some benefits of these application delivery methods include more provisioning control for IT, centralized management and easier patching and updating. But not all applications work well as remote or streaming apps, and administrators often run into network bandwidth issues.
In this Q&A, expert Alastair Cooke explains how application virtualization works and when it's useful.
How does application virtualization work?
Alastair Cooke: Remote and streaming applications execute an application that's not installed on the device in front of the user. A remote application runs on a computer somewhere else, in the data center. A streaming application is run from a network share that actually executes on the user's device.
Remoting is good if the user is accessing a variety of different devices. Today they're using their iPad, the next day they're using their home PC, for instance. Streaming is good for having more responsiveness in the application because it's running on the device itself. But it's limited to running only on the OS that the app would run on natively. So, if it's a Windows application, the device has to be a Windows PC.
What are some other benefits of application virtualization?
Cooke: Application streaming makes it very easy to deploy new versions of an application because you simply wrap the new app once and place it on the network share or the replication point, and the new application becomes available to all your users.
More on application virtualization
Application virtualization on the server side
Spotlight on Windows application virtualization
Using ThinApp for app virtualization
Application virtualization and the VDI app store
It also means there is no requirement for sociability testing among your upgrades. Because you put a runtime that provides essentially a virtualized file system and registry inside the application (and you're using an agent to deploy these applications), the application itself runs inside a sandbox so it can't impact another application that's installed in your environment.
Remoting can be very beneficial around patching and upgrading. Users are accessing an application that's running in the data center, so you have very high connectivity. The update challenges around WAN don't come into play when the execution is in the data center.
How does app virtualization affect application performance?
Cooke: For a streamed application, the virtualization of file systems and registries has a small impact. The application execution is potentially a little slower, but the user interface runs at the native speed of the device.
With remote applications, the actual execution tends to be very fast because it's running on data center-grade equipment. But the user interface has to be remoted out to wherever the user is -- and that's very dependent on the network between the data center and the end user's device. If they're using a low-power device like a cellphone to access an application, there may be some speed issues.
What kind of network challenges come with application virtualization?
Cooke: Latency is another issue: How long does it take to get the data back and forth? You can't change the speed of light! The further away you are from the data center, the longer it takes for the information to get to you. These factors can degrade the performance of an application's user interface.
Modern remote protocols have gotten very good at dealing with these issues. The effects of different network characteristics are different across different protocols. Some are very good with high latency. Some work well when bits of information are lost along the way; others are not so good.
Are there some applications that aren't worth virtualizing?
Cooke: It depends how you're going to use the app. A heavyweight CAD application that needs a lot of resources in the data center to do its job well, for instance, requires high latency and low bandwidth.
The larger and more complex the application, the harder it is to stream. You have to capture how an application works when it is installed locally, and it's hard to do that well.
How can application virtualization help VDI admins create disposable desktops?
Cooke: What most VDI deployments want is to get to a state where the virtual machine the user accesses is actually disposable -- you're persisting the user's environment but not the virtual machine. This helps with updates and support.
For [a customer of mine], the key to getting to a disposable desktop state was to virtualize all the applications that were only used by a small number of users. VMware ThinApp allowed them to go from applying disposable desktops to 20% of their staff to applying them to everybody that uses VDI. VDI pays off when you don't have anything unique to each user at the virtual machine-level.
What are some differences between VMware ThinApp and Citrix XenApp?
Cooke: These are application streaming products that are applicable to VDI environments and even conventional desktop environments. They capture an application by watching how it performs on a nice clean computer and then seeing the differences. … To run that captured environment, you need to provide the runtime for the virtualized file system and registry.
These two tools are very different in how they provide the runtime. With ThinApp, it's included inside every captured application, which is a very small number of files. XenApp and Microsoft App-V, as well as products such as Symantec's app streaming technology (formerly Altiris), rely on having an agent installed. For XenApp, you deploy an online plug-in, and for App-V you deploy a client.
When the runtime is inside the agent rather than inside the package, those products talk to a central management service. If all you have for a packaged application is an executable container with that virtualized file system, then all the policy and management has to be wrapped up in there as well. Plus, you can take a ThinApp package on a USB and use it in an airline lounge, whereas with XenApp or App-V you need to be connected to the management server. That means those packages often only run on devices owned by the company. To access a remote application on a device not owned by the company, you could use Remote Desktop Services to stream the application from the data center.
Updating is also done differently with the two technologies. For the ones using an agent, you update on the management server. With ThinApp, you update the copy that people download rather than updating a central copy.