So we have a new boss at TechTarget, Josh. He’s based on Boston but in SF for the week, and I asked him, “What’s the one thing about our industry that’s most confusing to you?"
He answered immediately: App virtualization. People use “app virtualization” to describe remote apps (XenApp, etc.), and for things like App-V and ThinApp, for “new” approaches like FSLogix, Liquidware, and AppVolumes. Citrix has AppDisk, Unidesk talks about layers (or not), people are talking about “container-based” solutions, and of course there’s also app streaming and app refactoring... But really what’s the difference? And how do these all work anyway?
So in this article, I’m going to attempt to sort this out. (For the techies reading this, you’ll see that I’ve dumbed things down a bit, and the examples are trivial, but the gist of things is correct.)
Just like how the word “virtualization” is overloaded to mean a bunch of different things depending on which vendor you talk to, the term “app virtualization” is also used by lots of different vendors to mean lots of different things. (Since app virtualization is hot right now, it seems that almost every vendor in our space has managed to apply the term to something they offer.)
Understanding traditional (not virtual) Windows applications
To understand the concept of app virtualization, we first need to look at how Windows desktop applications work when they’re *not* virtualized. (e.g. How things work the traditional way.)
When you install an application (like Microsoft Office) onto a Windows computer, the installer program puts lots of different files in many places on the computer. Actual program files that run Word are installed into C:\Program Files\Microsoft Office\. Some shared DLL files are put into the central Windows system folder. Font files go into the fonts folder. Personalization files might go into the user’s profile folder. Etc, etc. Long story short, there are files everywhere!
Windows computers also have the Registry which is a hierarchical database which contains all sorts of low-level system information, including how Windows system files work, device drivers, services, user interface settings, personalization settings, app settings, printer settings, file type associations, and about a million other little things. Most Windows desktop applications also add or modify registry keys they need to function properly.
Long story short, installing an application on a Windows computer copies lots of files to lots of different locations, and it adds and updates lots of registry keys it needs to work. This is fine when you just have one application installed, but as soon as you start installing more applications, things can get messed up.
- One application might install some shared DLL file to a system location, and then another application needs a different version of that file overwrites it, and now the first application doesn’t work.
- One application might install some shared file, then later you uninstall that application, and it removes that shared file not knowing that some other application needed it, and the other application breaks.
- One application might store its settings in a file like C:\windows\settings.ini, and a second completely unrelated application might *also* use C:\windows\settings.ini for its settings, and the two apps are confused because they’re trying to use the same settings file but for two different purposes.
- The same is also true for Windows services (two apps trying to install their own service with the same name), or with device drivers, or registry keys, or lots of other problems where things “crash."
In addition to the problems with different Windows applications breaking each other and generally not working well together, there are a few other limitations with traditionally-installed applications in virtual desktop environments, including:
- Many virtual desktop solutions are based on “shared” disk images used by lots of users. Unfortunately if you install applications in a traditional way, that means you have to essentially install every application that every user would ever need into your base image. Not only is this expensive (in terms of licensing because you need to license every user for every app), it also increases your chance that two apps will conflict with each other since you have so many apps.
- An alternative is to just install the apps that each users needs “on demand,” but as you know, installing new apps takes a long time (like what, 15 minutes to install Office), so it’s not practical to go through the whole application installation process for each user’s own apps every time they log in.
The solution? App virtualization!
Put simply, the solution to this is instead of actually installing your Windows applications in the traditional way, you “virtualize” them. At the most generic level, app virtualization just means that from the user’s standpoint, it appears as if an application is installed, but in reality it is not installed in the traditional way as I outlined above.
So how are virtualized apps installed? The answer really depends on what app virtualization technology is being used, since they all work in different ways. That said, ALL app virtualization solutions have two things in common:
- From the user’s perspective, a virtual app looks like a “regular” app. They just click the app name in the Start Menu, or they double-click a file to open it in an app, and boom, the app pops up and they’re using it like normal.
- Even though the app looks and feels like a normal app, it was *not* installed like a normal app.
Let’s dig into all the different types of app virtualization (in random order):
App Virtualization Technique #1: Remote Applications
The first type of app virtualization can be called “remote apps”, “app remoting”, or sometimes “server-based applications.” With remote apps, the Windows application is not installed on the computer the user is using. Instead it’s installed on some other Windows computer. (That computer could be on premises in the company’s own datacenter, or at a remote hosting company, or in the cloud.)
With app remoting, the application is running on a remote Windows computer, but the individual pixels that make up the application’s window(s) are transmitted from the remote computer to the user’s computer. Think of this like Netflix streaming for apps. The app is running somewhere else, but the window frame showing the app is on the user’s computer, so the user thinks the app is running locally. (Obviously also any keys the user pushes and mouse clicks are transmitted up from their computer to the remote copy of the application.)
Remote apps often integrate with the Windows desktop in a way that feels seamless. For example, the user can move the application window around and resize it. They can ALT+TAB to switch apps, and then can click the app’s name in the start menu to launch the app. But again, the app is never installed on the user’s computer—instead it’s running somewhere else with just live streamed pixels from the app showing up on the user’s screen.
Products that do remote apps include Citrix XenApp, Citrix XenDesktop, VMware Horizon, Dell vWorkspace, and Microsoft RDSH. This is also the technology that DaaS providers use. The exact network protocol that transmits the remote pictures of the app down to the user’s computer is dedicated to this purpose, and each different vendor has their own protocol. (Citrix HDX, Microsoft RemoteFX, VMware PC-over-IP, etc.)
Some big cloud providers offer app remoting solutions as well. For example, Azure has a product offering called “Azure RemoteApp” which is literally where you install a Windows application into the Azure cloud and then users access it via this remote control style and it looks and feels like it is running locally even though it’s in the cloud.
Advantages of remote applications
- There are no conflicts between different apps on a user’s computer since the remote apps are not actually installed on their computer.
- Since the remote apps don’t run on the user’s computer, they can be accessed from computers that do not run Windows. (For example, Mac users could access Windows-only apps from their Mac since the app is really running on a Windows computer somewhere else and just the pictures of the app are sent to the user.)
- A remote app is available “instantly” to a user, even if they never used it before. The user just clicks the app icon and they can start using it right away.
- When it’s time to remove an app from a user, the IT department simply takes away that user’s permissions to use the apps. There’s nothing to uninstall or remove on the user’s computer, and it won’t break anything on the user’s computer.
- When the IT department has to upgrade an application, instead of going around to hundreds of users’ desktops and upgrading the app there, they simply upgrade the copy of the app on their servers.
- Side-by-side apps that might conflict can still be used by a single user, because the remote apps could be installed into separate servers (where they don’t conflict), and the user could use them both at the same time. It would look like the user is running conflicting apps side-by-side, but really they’re just streamed pixels of the apps from two different servers.
- A user can disconnect from a running remote app and then reconnect later from a different computer. (e.g. They can start at work and finish at home.) This can be nice because they can access their fully running work environment from anywhere without having to install work applications on their home computer or lug a laptop back and forth.
- If all a user’s apps are remote apps, the expensive and difficult-to-maintain desktop computer can be replaced with a cheaper and unbreakable thin client, meaning that IT spends less time at users’ desktops fixing their desktops.
- If a user loses their laptop or burglars come in and steal all the computers, no sensitive data is lost because the apps were never actually installed on their computers.
- If the user's computer is old or slow, the remote app still feels nice and fast since it's not actually running on the client computer.
Disadvantages of remote applications
- Since remote apps run on servers and not the users’ computers, the users’ computers have to be connected to the servers for the entire time they’re using the app. In other words, you can’t use remote apps on airplanes and other times where you don’t have a network connection.
- Sometimes graphically-intense applications don’t work too well since they might be changing too many pixels on the screen too fast and it’s hard for the network to keep up (or it takes a lot of bandwidth).
- If the network connection is slow between the user and the remote app, using the app can be painful. Sometimes there could be “lag” between the time the user hits a key on their keyboard and when the character actually shows up on their screen (since the keystroke has to be transmitted from the user’s computer to the remote app, and then the remote app has to draw the character on the screen and send down the changed pixels to the user’s computer).
- Certain peripherals can be more complicated to get working, or maybe even though won’t work at all. This is especially true with peripherals that use a lot of data, like webcams.
- Things like printing can be complex, because when the user hits “print” within the remote app, the print job is created on the remote Windows server, but the printer is down by the user, so there needs to be a way for the remote server to know which printer the user needs, and the right printer drivers have to be installed.
- Sometimes it can be tricky to get local and remote applications to integrate properly. For example, what if you have an app that requires Microsoft Word to generate reports, but that app is a remote app and the user has Word installed on their computer. They’ll get an error saying “Word not found” even though the user is cursing, saying, “But I see Word right here!” But really Word isn’t right there. :)The bottom line with remote apps is that the Windows application *is* technically installed in the traditional way—except it’s installed traditionally on some remote server, not on the user’s desktop computer.
The bottom line with remote apps is that the Windows application *is* technically installed in the traditional way—except it’s installed traditionally on some remote server, not on the user’s desktop computer.
Next: Local Apps
I originally thought that I’d write this entire article as a single post, but now I’m up to 2100 words and I’ve only covered one type of app virtualization! So instead I’m converting this into a weekly series, where each week I’ll write about a different type of app virtualization. I don’t know how many parts there will be. Probably 4 or 5 total.