Simplicity through Complexity

The rate of change in the technology field is relentless. Constantly there are new solutions and products changing the status quo. This is especially true in the area of virtualization. We now have:

  • virtual servers
  • virtual desktops
  • virtual applications
  • virtual appliances
  • virtual fabrics
  • virtual switches
  • and so on, and so on…

So where does this get us, apart from learning a bunch of new solutions that all seem more complicated than the way things were one before. The answer is simplicity, these technical solutions are all leading to one thing: abstraction. What this means is that they are removing dependencies in the stack from one another. Less dependencies, less complexity, more agility and freedom.

They’ve talked about this model in many capacities in different areas of virtualization; a common one is the layers of cake, or simply the layers model in VDI. Where the OS is decoupled from the applications and user profile. All the components come together to achieve the end result of a functional user workspace, yet none of the components are dependent on the others.

This facilitates simplified rollouts, migrations and upgrades. Admins no longer need to be concerned of adverse interactions with the upgrade of any one particular component, instead each component can be dealt with independently. This vastly simplifies change management and regression testing. It also enhances portability, users can bring their profile or applications to any OS with minimal headaches.

I have been doing research into Microsoft SCVMM 2012 and that was when I saw this model being taken and applied to server virtualization. Let me tell you- it was impressive. Microsoft has a product called Server App-V which like its MDOP counterpart, which virtualizes desktop applications, it allows for the virtualization of server workloads. Things like IIS, SQL Reporting Services or XenApp for example can be virtualized.


server app-v application compatibility

Application Compatibility

The ability to virtualize server workloads really starts to shine when you look at the rest of the capability of SCVMM 2012. SCVMM is moving towards the goal of providing resources regardless of location or hosting platform. Resources are no longer merely virtual machines, storage and networking but are tied together as services including the application layer. These services can be templated and basically act as a “recipe” for fully functional services such as a online purchasing system or XenApp host. This facilitates simplified user self service for deployment of services on demand. The fact that all the components of the “recipe” are virtualized and abstracted means extreme portability (think moving to the cloud!). Components can be upgraded independently and without concern of the other components. Think of how much this will simplify deployment.

Server App-V can take an application that has a 200 page installation guide and contain it so that every deployment is identical after the first succesful one. It can be ported from development to production and back again without ever changing. Any application changes and config is captured as “state”. Server App-V can monitor and port this state data so it can be migrated simply as well. Server App-V is a feature of SCVMM 2012. This means that all this can be automated in SCVMM’s console. It lets you visually define the components of a service and save it as a service template.

It is really exciting to think that one day incompatability type issues will no longer be a major headache. Everything will just work, as it is no longer some huge infrastructure stack with hooks running between all the layers, but rather a series of clean, known good, abstracted layers. Layers that can be moved between the datacenter and the cloud. The vision is starting to shine, and the clouds are starting to clear 😉

Server App-V Summary

How to video : Sequencing an application with Server App-V

Video: Server App-V TechEd Presentation


Citrix XenApp Streaming – The What and Why

XenApp Streaming has been around a while now, with the most current release included in XenApp 6. For those of you who aren’t too familiar with streaming it allows an administrator to capture an application install as a package (.profile extension) which is then saved to a file share.

From there users can launch the application at which time it is streamed in real time and executes locally where the streaming client is running. In some cases this is then delivered via ICA in a “Streamed to server” environment. With the streamed to server XenApp administrators can avoid unnecessary silos of XenApp servers.

So whats the big deal?

Good question, streaming allows applications to be isolated in that they have no ability to modify or write to the underlying operating system, either in the file system or the registry.

So whats the big deal?

Another good question! The benefit of this is that applications that may not have been compatible on a single system in the past, can now be delivered and run concurrently. For example this would allow a user to run Office 2003, 2007 and 2010 applications all on the same system. All without ever having to install the application once!

From an administrative standpoint, it allows a single streamed package to be maintained. Lets say a service pack is released for the users application, this can be applied to the application package and users will receive the updated package the next time they launch the application. This can even be done without an outage as users currently in the application would not be affected. This simplifies things for an administrator as now they only have to update a single instance of the application rather than every copy for every user!

Another plus, is stability of the system running the streamed applications. We all know with every application that gets installed, and possibly later uninstalled, operating system performance degrades over time. This is due to applications modifying the underlying OS. As stated previously streaming does not modify anything and is completely isolated in its package, therefore leading to a cleaner system and hopefully more stable system.

Great you say- are there any drawbacks?

With streaming it can be a lot more tricky to troubleshoot an application that does not work. Although if it works it will tend to stay working as the application package is read only. Additionally some applications that are improperly coded will often fail in an isolated streamed package as the restrictions will not be conducive to the improper application calls.

Some applications will flat out not work. I’ve been having lots of fun trying to get Office 2010 to work and it appears the changes to MS licensing are causing me grief. This is a good example where even though the application streams, there is a license lookup that fails currently in the streamed environment. I am still investigating this and will have a solution when I find one.

What about App-V?

Microsoft has their own streaming software called App-V. This was originally known as softgrid. The technology is effectively the same but handles things a little differently so some applications that don’t work in Citrix packages may work in Microsoft and vice versa. The nice thing is that XenApp supports publishing App-V packages natively within a XenApp farm.