Application Distribution via Streaming

Wall Street Journal had an article today about application virtualization at the desktop. I never thought I’d see the day when this topic would end up in the ‘Journal. Wow.

The thing that makes me cringe is thinking about the conversations we've had with customers on thsi topic at the Microsoft Technology Center Chicago. We're having flashbacks to infrastructure discussions held back in 2003, and in this case hoping history doesn’t repeat itself.

Think back to the early 2000s: server consolidation was the buzzword, and every IT department soon had this initiative in their portfolio of projects to complete to “reduce costs”. All my customers wanted to throw hoards of physical servers onto one big server to increase their optimization, usually through virtualization. What we quickly learned from customers was there were several approaches to server consolidation, not just virtualization, and taking a step back and choosing the most appropriate approach to consolidation became the most important factor in predicting success. For example, its very possible and achievable to consolidate File and Print services, or Exchange email services or SQL databases, onto fewer number of like boxes without having to virtualize.

We saw some glorious failures out during that euphoric consolidation wave, and we can take the same learning’s and apply them to the newest buzzword: application virtualization (we’ve also heard it referred to as “OS streaming” and “on demand installs”). When we saw the first wave of server consolidation hit, IT shops wanted to stack tons of servers onto few number of physical boxes. What we learned was:

- There are many approaches to consolidation, and some thought needs to go into which is the most appropriate

- Good IT practices (change management, monitoring, etc.) trump any technology solution

Introduction to Application Virtualization and “Streaming”

If you aren’t familiar with application virtualization, it’s taking an applications running instance (installation, execution, etc.) and encapsulating it, so it can run in its own isolated environment on a workstation. Microsoft’s solution in this area is called Microsoft Application Virtualization (MAV), previously known as SoftGrid. This solution is part of Microsoft’s Virtualization portfolio which includes server virtualization, presentation virtualization, and desktop virtualization.

Application streaming to desktop is somewhat new and has lots of attention (see Gartner’s Hype Cycle for PC Technologies, June 25,2007). Microsoft purchased SoftGrid about a year ago to have a solution this space, and it’s a pretty compelling solution as are others out there with a lot of viable implementations.

As we move to application streaming, we start shifting the “work” to other components. It inherently increases the reliance on other core components, most importantly the network and general connectivity. For example, another virtualization technology solution in the space takes an entire application and compiles it into one .EXE by taking a snapshot before and after an application installation. Therefore, it’s highly isolated from other apps that run. But, this requires the network to be always available, must be capable of a large increased load of transferring the entire .EXE across the network in one big bite. MAV, on the other hand, transfers only what is needed and not the entire application, but still has a (reduced) reliance on the network.

Suitability for all situations

This has some real potential for organizations where there are large number applications, often due to factors like acquisition or consolidation in an industry (such as healthcare). Another is where multiple distributed IT departments have come under one umbrella as a part of IT consolidation, removing departmental or divisional IT groups and collapsing into one. So, now where each division may have had its own order system or HR system for example, now may need to run several side by side. With every app isolated, this becomes a very compelling option due to the large number of application install combinations per workstation. The result of all these apps that need to run side by side would be a large and impractical testing matrix. Value form app virtualization would come from the reduction of time needed to test out the different iterations of application compatibility.

Where we have the most concern are the IT departments which are engulfed in the hype to the point where this is the solution (similar to server consolidation), without considering other factors such as their ability to support this environment.

Impacts of streaming

Streaming removes some big headaches. But, it has some caveats:

The IT groups must have a highly reliable set of operational practices, and robust experiences in network and application performance monitoring. Your dependant components (parent or host OS, router, application, workstation, etc.) has to expose out performance information. Also, your management tools must be there to capture and smartly digest that performance information into actionable tasks. This is probably the single, biggest overlooked area in all of virtualization (such as server virtualization, where there’s a strong need to monitor the host in addition to the child VMs themselves).

Bottom line:

1) If you aren’t using good IT operational practices today, such as MOF or ITIL, you better start and get good before taking on immature technologies such as OS streaming. Good IT practices trump the best technology solutions.

2) If you aren’t that mature in IT operational processes (see IT Infrastructure optimization), you might be better consider more mature solutions like traditional application packaging and distribution. This is a very proven and established solution with a lot less risk.

3) If your organization is not traditionally an early adopter to leading edge solutions, your audience probably won’t have the appetite for such a bleeding edge technology. We’d encourage copious amounts of testing and validation for performance, network latency, etc.