This article is Part 5 in a series about app virtualization. The other parts are:
In today’s article, we’re going to cover the technology called “streaming."
Streaming is actually an old term (well, “old” in the IT sense) as it’s been around for over ten years. In fact in the early days of app virtualization, “app virtualization” and “app streaming” were typically used interchangeably.
Like all the other app virtualization technologies we’ve been talking about in this series, the base concepts of app streaming are built on other app virtualization technologies. When app streaming is used, there’s a streaming software agent installed on a Windows computer (whether it’s a physical desktop, a laptop, or a VDI virtual machine), and that software agent “tricks” the Windows OS into thinking a particular application is installed normally even though it’s not.
To understand how streaming works, it’s probably easiest to look at some of the limitations of the other app virtualization technologies we’ve talked about.
When we talked about virtual locally-installed apps back in Part 2, we discussed how Windows apps could be “packaged” into virtual apps which could be installed onto a Windows client. In Part 3, we talked about how groups of virtual apps could be combined into “layers” which could be enabled or disabled (on demand) on a Windows client.
One thing we glossed over, though, was “How do those app packages or layers actually get transferred onto the client computer?" How do they make it from the server or datacenter onto a user’s laptop? This is where streaming comes in.
In the old days (before app virtualization), if you wanted to install an application onto a computer, you inserted a CD and ran the setup program. The “bits” that made up the Windows apps lived on the CD in the form of files, and the setup program would copy all the files from the CD to the necessary locations on the computer. Once the app was installed, you didn’t need the CD anymore.
In more modern times, downloads from the internet replaced CDs, but the concept is the same. You download the app’s installation program which contains zipped copies of all the files the application needs, then you run the setup program which copies those files to the proper locations on the Windows computer. Once that’s done, you can delete the original setup program you downloaded since all the files are in their final locations.
Both of these file copying techniques were fine in the days of traditionally-installed applications since most people didn’t install new applications that often, and when they did it was typically only something they did once when the computer was being set up. But remember that one of the great advantages of app virtualization is that it makes it easy to “install” and “remove” applications (or to “show” or “hide” them), and it’s possible virtualize dozens (or even hundreds) of apps since individual users only “see” the apps that they’re actually supposed to see and applications don’t conflict with each other.
So you can imagine a scenario in a modern app virtualization world where a user logs into a blank, empty Windows desktop, and then once they log in, the app virtualization software kicks into gear and downloads all the virtual app packages that user needs. This is a nice way to manage things since you don’t have to maintain separate combinations of apps for all your users, rather, you can just manage a single base copy of Windows and then let app virtualization make sure each user can see their own apps.
The problem with this is that you still have to figure out a manageable way to physically copy the “bits” that make up the virtual app from some server in your datacenter where all the virtual app packages live down to your users’ computers. But since today’s users need access to lots of applications, and today's applications can easily be several gigabytes in size, you can imagine a scenario where the user logs in and then the system says, “Please wait 20 minutes while we download all your virtual app packages."
The idea with app streaming is that the actual “bits” that make up an application are not copied to the user’s computer until they actually try to use that app. This is nice since not every user uses every app every day. (And even for users who do use a lot of apps, they don’t launch them all at once right when they login.) Really when a user logs in, all they actually *need* is for the icons for the apps to be there in the Start Menu. As long as the user sees those icons, they know everything is ok, and they know that they could launch any one of those apps if they wanted to.
So with app streaming, if a user has access to 20 different applications, the app virtualization / streaming software on the user’s computer doesn’t actually need to download 20+ gigabytes of application “bits” to the computer, rather, it might only need 1% (or less) of those “bits”—just enough to make it look like the application is installed.
The real magic happens when the user actually launches an application. Remember that app virtualization works by having a software agent that tricks Windows into thinking the app is installed normally even though it isn’t. This is no different for streaming. The app streaming agent says, “Yeah, you have Microsoft Word. Here’s the icon. You can click it any time.” When the user actually clicks that icon to launch Word, the app streaming agent tells Windows that the files and registry keys that Word needs to run are there, but really it’s contacting the app streaming server in the background and saying, “Hey! Hurry up and send me Word since this user is trying to use it.” Since computers and networks are fast these days, this can all happen in the background, typically quick enough that the user doesn’t even know it’s going on.
This is similar to how a music streaming app like Spotify works. When you install the Spotify client on your computer, it looks like you have millions of MP3 files sitting on your computer ready to play. But really there’s nothing there—all the songs live on a server on the internet. Then when you play a song, it’s streamed down from the internet on demand. So it plays and behaves like a normal MP3 file even though it’s streaming from the internet.
The app streaming software is smart about how it requests and streams the “bits” that an application needs. For example, Microsoft Word is almost 1 gigabyte in size. Even on a fast network, that could take a few minutes to copy down to the client computer, and it would be annoying for users to have to wait that long just to launch Word. But the reason Word is 1 gigabyte is because there are a million features in Word to do hundreds of obscure little things that most people don’t use. The code for all those features is spread throughout hundreds of separate files that make up the Microsoft Word package. But how many of those features do you actually need just to launch Word? Not many! (Honestly probably not too much more than the “splash screen” that says Word is loading, and then the bits that make up the main Word new document screen and the menu bars and ribbon and stuff.)
So even though Word is 1 gigabyte in size, the app streaming software can actually get Word up and running with maybe only 1 or 2% of the total “bits” that make up the entire Word package. What’s really cool is that these app streaming products can actually break up the files in an application package into little chunks and just copy down the specific chunks of the specific files that are needed. So if a user never uses Word’s table drawing features, those “bits” will never be copied down to their computer. (And of course if they do click on the table drawing menu item, the app streaming software will just grab those specific bits from the server right then and there, and the user is able to use those features just like normal.)
App streaming is nice because you get the benefits of locally-install virtual apps without having to take up all the hard drive space for all the apps to be installed. (This is a similar benefit to the “remote apps” style of app virtualization we discussed in Part 1, except with streaming the app is actually running locally on the client computer which can often lead to better performance, which can work offline, and which doesn’t require server infrastructure to host remote app sessions.)
App streaming clients can be configured to keep the bits of applications that have previously been streamed so they don’t have to be re-streamed every time, and they can also be configured to “pre-stream” certain apps so that the user can use them without a network connection to the streaming server (like when the user is traveling).
App streaming is also a nice way to manage the updating of virtual app packages. For example, if a security update for Word is released, the app streaming agents only need to re-stream the actual bits that were updated rather than the entire package.
As mentioned already, app streaming is not a standalone product, rather, it’s a delivery option that is used in conjunction with other app virtualization products. (In fact you can’t even buy a standalone streaming product anymore—it’s just a “feature” of other products.)
App streaming doesn’t make sense in every use case. For example, many VDI environments don’t actually need app streaming since all the storage powering them is virtualized, so the VDI instance can think it has all the app packages installed locally and the storage system takes care of the logistics. But for traditional desktops and laptops, app streaming still has a place in 2016.