Layering is an emerging concept for VDI. I am not going to try to explain layering in this post, rather I am going to discuss one aspect of layering – the user installed applications layer. For more information about what layering is, how it is done, and how it fits into VDI, check out Gabe Knuth’s article.
Service Oriented Architecture
Layering is a new take on an old concept in my mind. I see layering as an implementation of SOA for desktops. A key concept of SOA is loose coupling. Loose coupling involves a consumer and a service. The consumer doesn’t need to know how a service is implemented. All the consumer needs to know is how to interface with the service. The consumer asks the service to do something and the service does it (and possibly returns something to the consumer).
Here is a real life example to illustrate: When I stay at a hotel, I usually call the front desk to schedule a wake up call. The front desk takes my information and calls me when I ask. In this example, I am the consumer and the wake up call is the service. I do not necessarily know how the front desk implements the wake up call – they can put the time in a computer to have an automated system call me, or maybe they write it on a call log and a human actually calls me. The point is, I don’t know (or care) how the service is implemented.
Another aspect of loose coupling is that the services are interchangeable. So, in the example above, if the hotel is using some manual method and decides to use an automated method, that is fine. The service still gets implemented for the consumer because the consumer interface did not change.
So, if each layer is viewed as a service (and potential consumer), then the gaps between the layers are the interfaces. Also, if each layer is a service, then each service should be interchangeable. This example works pretty well for things like the hypervisor layer (swapping in and out VMware/XenServer/Hyper-V), but maybe not so well for applications, since applications may have dependencies on one or more layers. Application virtualization can overcome this by packing the entire stack necessary for an application in a bubble, but do you really want to teach users the intricacies of sequencing (or profiling) applications to solve a user installed app layer?
So, this got me to thinking, is reverse seamless an answer for a user installed application layer? If you rely on your local desktop for user installed applications and present these applications seamlessly in a remote desktop, will that suffice? Maybe – maybe not. If the user installed applications want to interact with remote applications, you have a problem. If not, then yeah, maybe reverse seamless does solve this.
VDI/XenApp Double Hop
A side effect of reverse seamless is that it also solves VDI “double hop” issues when using XenApp published applications inside a VDI desktop. For example, if you allow client drive mapping from the local desktop to the VDI desktop, and you also allow client drive mapping from the VDI desktop to the published application, then end user will quickly become confused as to which drive is which when trying to save a file from the published application. Think about printing and USB redirection also.
By using reverse seamless, both the VDI connection and the published application connection can be made from the local desktop, then “merged” seamlessly. This way, the VDI desktop is making one hop and the published application is making one hop. You still have a problem if the published applications needs to interact with the desktop applications.
Type 1 client hypervisor
Will a type 1 hypervisor help with user installed applications? I think this has the most potential. Running a “personal” VM and “business” VM on the same physical hardware, there are all types of interaction that can happen. If users install applications on the personal VM, reverse seamless type technology could be used to integrate this layer in a more cohesive way.
I guess the bottom line is that user installed applications in a stateless layered model is going to be hard.