While we're in the process of figuring out the new “desktop” (small “d”), we have a lot of different ideas and models for how to layer and manage our stuff. None of the models seems quite right to me, and over the past few months I've been struggling for a way to describe why. I think I finally have some ideas down that I think I’m ready to share:
The traditional PC: The "Blob" Model
The traditional PC can be described as “The Blob”. In “The Blob”, there is no real separation between the operating system, applications, and the other stuff which for simplicity I will call “Application Related Data” (or ARD). There are files all over the place in the file system and crud all over the registry. Not organized and certainly not a pretty sight. When we want to do unnatural acts, such as to replace out the hardware or operating system, or more bizarre things like allow the user to roam to different operating systems, or even to be logged into multiple operating systems at the same time, I think we can all agree that the model of “The Blob” is butt ugly.
To some extent, we have not had to worry too much about the blob in the enterprise. Vista was widely ignored and the major concern was when a user got new hardware. Sometimes that meant just copying over the partition image, but when not we could build an OS and App image that matched and then use tools to migrate the user data. This apples-to-apples copy works reasonably because it is simple.
In a session I did at BriForum in Darmstadt a number of years back, I attempted to frame the problem. I broke the “ARD” category into eight different sub-categories of stuff that might need to be treated differently if we could only do the categorization properly. This proved way too complicated for people to deal comprehend easily, and certainly well beyond the ability for anyone to act upon after the blob is already created. In fact I concluded in that session that we really need the app developers to help us out of the problem, and that we really need Microsoft to lead them to start making new applications with organized data into these sub-categories. This isn't happening and isn't about to. Oh if I could be Bill Gates, just for one day...
The “Layer Cake” Model
Today people are busy migrating from the Windows XP blobs they have to Windows 7. Most are at least playing with VDI, and hoping that they can make it work with a shared OS image. The model that we typically see is referred to as “The Layer Cake”. By separating all of the stuff that is in The Blob into three different layers we, in theory, could have a simple model to deal with that would allow portability and flexibility in deployment. The claim is made that it is as simple as swapping out the OS layer to perform an upgrade.
When you see this model, you first need to recognize that we are talking about only a new deployment. You don’t really transform The Blob, but lay out an image in this format from the start. There are migration tools and vendors to help bring things over, but fundamentally you want to think of this as a fresh deployment. But I don’t like Layer Cake as a model at all. Unfortunately, it is too simplistic to work well enough in complex application environments in the long run. I’ll explain that statement in a long-winded way.
“The AppVirt” Model
Another trend I see happening as companies move to Windows 7 is that they are adopting application virtualization in a widespread way. They know that they have lots of application issues, and the major one is conflict between applications. AppVirt has proven itself as the best solution to this problem. [Side note: It is ironic that it took so long for mass adoption of AppVirt. While we still have significant application conflict issues, much of the worst applications are being or have been retired. But I guess you only need one business critical app to be the problem!] But containerizing and isolating applications is also a smart move to enable flexibility and portability, both today and in the future. But the AppVirt model looks like the drawing on the left.
We have been successfully using this model for ten years now. AppVirt allows us to deliver and maintain OS, App (Application components and base configuration), and User-based-ARD separately from each other, with proven ability to roam between machines and operating systems and considerable ability to upgrade the application without losing the user’s ARD. Unfortunately AppVirt isn’t perfect either. Not every app can be put into a container. The list of applications not supported by AppVirt grows smaller each year, but it is still significant enough that AppVirt by itself is not a 100% solution.
The “Pillar Cake” Model
So what do people do, combine these models? They are trying to. I don’t see vendors show the model drawing I have below, but they certainly feel that combing “User Environment” products with AppVirt solves all of you problems. I see customers struggle with implementing this, and probably mostly because nobody wants to understand the application details enough. The first attempt typically looks like this:
A nice simple picture that combines the best of both worlds, right? No. Application conflict, it turns out is about more than conflict of the App later, but also often conflict at the ARD layer as well. We see this all the time when two versions of an app are needed by the same user, maybe Office 2010 for general use but Word 2003 needed for another app. If you take out the ARD separation, you have a problem. So what do you do?
The “Chinese Menu” Model
Here in the US when I was younger you might go to a “Chinese” Restaurant and rather than the combination plates you see on the menu today, they had columns with the different types of food. To order, you picked the items you wanted from each column. For those unfamiliar, we refer to this as a Chinese Menu. To combine AppVirt with User Environment you need to use the “Chinese Menu” Model.
In reality it becomes more complicated than the drawing above; with any given application there may be need for some ARD to stay in the AppVirt layer and some to be in the user layer. But there are still more complications. First, let’s look at the latest complications in AppVirt.
The “AppVirt DSC” Model
Applications sometimes integrate with each other, so full separation isn’t always a good thing. Often, the integration is just on a file basis and this isn’t a problem. Other times, we just build an application suite container with all of the inter-dependent applications and it acts as a single application for the purpose of our models. But some applications are more like application platforms with lots of tentacles. Microsoft Office is a prime example. The single package approach quickly turns into a nightmare there. So instead we create application suites. App-V uses the term “Dynamic Suite Composition” (DSC) and so I’ll use DSC here as a generic term. Depending on how DSC is done, you might end up with a model that looks like either of the drawings below:
The “Tetris 3D” Model
When I start thinking about combining all of this into a single model my mind currently turns to an old video game, Tetris3D (I can’t find the original DOS game, but here is a clone called 3dTetris ). Tetris3D was a game where you had all sorts of odd shaped blocks that dropped into box and you had to rotate them in three dimentions into position while dropping to get them all to fit. When you filled a layer it was removed from the game to make room for more blocks. In the PC image model game, we don’t get layers removed when a layer gets filled, but right now that is my working model. Maybe one of those wooden puzzles where you have to put all of the pieces in the right order could be the model also, but I think what we have is more complex: more parts, more than one “right” answer, and I like the never ending aspect of Tetris3D (there is always another app to add to the mix). It may not be the best model, since it took all of the above to explain it, but it is the best I have right now.
My belief is that we don’t have good enough solutions for handling applications and related data today. I conclude this because, in part, we do not know what the right model to frame the problem is. By no means do I claim that the Tetris3D model the right model; I’m simply using it as a way to convey how messed up our other models are.
The ultimate model and solutions must be simple, like the layer cake, to just catch everything automatically, but must also involve the deep understanding of App/ARD separation to make everything work. Separation into manageable categories is required for the flexibilities we desire. Otherwise, I just VM the problem away (leaving it to the user to figure out where there stuff is) or re-write everything as a cloud app.
Author: Tim Mangan is a Microsoft MVP for App-V, a Citrix CTP (I know, redundancy) and holds the position of Kahuna at TMurgent Technologies. He has spoken at every BriForum and at many other venues. Read more at his home blog or website, or follow him on Twitter as @TimothyMangan.