Parsing virtual apps, streaming and isolation

"Application virtualization" is a big part of desktop virtualization. In the past, the terms "application virtualization" and "application streaming" have been used interchangeably. Today, however, there's a difference in their definitions. In this week's column, Brian distinguishes their differences and helps you figure out which one is right for you.

Application Virtualization
"Virtualization" is anytime you separate the physical instance of something from the management of it. The following is a quick breakdown:

• Server virtualization is separating the management of a server from the physical server hardware.
• Desktop virtualization is separating the management of the desktop from the physical desktop device.
• Application virtualization is the separation of the management of the applications from the physical devices on which they're installed.

By this definition, an argument can be made that any automated application management tool, like SMS or Altiris, is technically a form of application virtualization; since those tools enable the remote deployment of apps to client devices via centralized management consoles. While that's definitely true, that's not what the term "application virtualization" has come to mean in today's world.

Today, application virtualization is the umbrella term used to describe technology that allows applications to run on a Windows computer without actually being installed first. Remember the old days, when you could launch an .EXE from a network share and it would just work? In those days, you didn't have to install or update apps on all your desktops. Updates were made to the one .EXE on the network, and the next time a user ran it, they were instantly running the newest version.

Now that we have laptops that need to work offline, applications that are complex and need to be installed, run various services, etc. -- you typically can't run an application before it's installed.

Well, application virtualization tried to fix this problem. Most application virtualization enable you to "package" your applications, which means that you install them first onto a test computer where special packaging software "watches" the installation process and records everything that happens (files copied, registry keys added, services installed, DLLs and COM objects registered, etc.). These packagers then bundle everything together into a tidy little package that can be run anywhere, with all the components put inside a single file that "just runs."

Application Isolation
As anyone who's been in the IT industry for more than five minutes knows, not all applications play nice with each other. It's very common for one app to conflict with another.

Application isolation takes application virtualization one step farther, by wrapping each virtualized application in its own protective bubble. In doing so, each application thinks it's the only app running, and any writes or changes it makes to the host system or registry are transparently intercepted and redirected to alternate locations, instead of the real locations, so that no conflicts occur.

From a practical standpoint, application isolation is conceptually similar to hardware virtualization, in that each instance of an app is isolated from other instances.

Application isolation was invented to deal with the "unknown" of client computers. App virtualization was a nice way to package apps to be sent to users, but all too often, those virtualized apps conflicted with local apps. Adding an application isolation capability fixes that issue.

Application Streaming
Now that you have all your applications packaged up and sitting on a server, the next step is to get them down to your client workstations. Since some of your apps are over a gigabyte, you can't just copy them down to all your users.

This is where application streaming comes in. Application streaming allows you to make a list of applications available to your users without actually copying any of the application packages down to your users' computers. When a user clicks a link to run an app, the system starts copying the package down to the client. The user is actually able to start using the application before the whole thing has been copied down. An application like Microsoft Word might start executing locally on the client with as little as 30 or 40 MB copied down, even though the entire package is a gigabyte. There's also intelligence built-in to the streaming software that will ensure that components of the application the users accesses are copied on-demand to the client.

Of course when applications are streamed, the user can't go offline unless the entire application has been copied down. This is something a user can usually do with a simple right-click 'checkout' option.

By combining application virtualization, isolation and streaming, you can craft a solution that works for you. Keep in mind that these features are not mutually exclusive. In other words, you might want to not use isolation if you need to integrate virtual and local apps together, while at the same time choosing to stream the virtual apps. The choice is yours.

ABOUT THE AUTHOR:
Brian Madden is known throughout the world as an opinionated, super technical, fiercely independent desktop virtualization expert. He's written several books and over 1,000 articles about desktop and application virtualization. Brian'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. Brian is also the creator of BriForum, the premier independent application delivery technical conference.