Demo of SCCM R2 w/App-V from Microsoft World Partner Conference
Posted by Jason Davidson Jul 22, 2008
A few weeks back at the BriForum I attended a session called The Future of Client Computing, where the audience participated in an open discussion around where client computing is headed. It was amazing to see a group of very smart people come to a single consensus...with various interpretations of that consensus I am sure. Being that I am back from the show, and back from vacation, I wanted to take a few minutes to recap what my interpretation of the future...
Therefore, the future from my eyes looks something like the following. I welcome your comments, disagreements, agreements, or snarky remarks. I will try to keep this write-up as vendor agnostic as possible...all characters appearing in this work are fictitious, any resemblance to real persons, living or dead, is purely coincidental, no animals were harmed in the making of this blog...and if this future plays out, I am not responsible for the results. 
Let me start by explaining where many of us are now. We typically live in a world where we boot a computer to a rich operating system that has many features we may or may not use, then we install applications off CD/DVD, downloading installers over the internet, or have it pushed as a local install over the corporate network. We all run local virus scanners, firewalls, and patch/update everything often - less we fall behind and become vulnerable. Each of these software programs we use have been tested to work with our operating system (or we hope), but very few of them are tested to work with other applications, and some are just not compatible with each other (they didn't make it out of kindergarten with the "plays well with others" moniker). Many programs are installed on a ton of computers, with much of the data being the same across those computers, but being that content belongs to the person next to you, it is redundant but not accessible (across a given large group of people the amount of duplicate data is enormous...larger than having copies of the US library of congress in digital format). Some people have started moving away from this model, but often come up with solutions that are either too awkward to become mainstream, or too limited to become useful.
Next, the path to the future... With several compute model choices, people have started using the modern day compute and network resources to revisit solutions that had limited success in the past (I say limited as none of them won out over the model described above, many were very successful in specific environments). To help with the large amount of redundant data, people moved the data to server rooms. To deal with application conflicts people gave each of these programs their own virtual sandbox to play in (now they don't have to play well with others...they get their own sandbox instead). To deal with patches and updates, people developed utilities to maintain compliance with a few button clicks (and several scripts, settings, and close monitoring). And the list goes on...
The future... Now I will put on my rose colored glasses and look at where things are going...in other words, I believe they are taking a turn for the better. Going back to the discussion that was had during the BriForum class, the basic architecture was a "dial-tone OS" with virtual containers that can be streamed and executed locally or presented over the network. The term dial-tone OS was new to me, and as I believe Ron Oglesby described it, the operating system would give a basic level of functionality similar to when you pick up a phone and hear the dial tone. We all have grown to expect a dial tone when you pick up the receiver, and if there is a pause or delay we are very confused as we have grown a very high level of expectation for the quality of service on this device (not talking about coverage areas here - just the basic features). With a dial-tone OS, the client device would quickly respond with some basic features - a GUI (graphical user interface)/window manager, a scheduler, I/O mapper, device drivers, and a virtual machine manager (I may be missing a few OS fundamentals, but the idea here is a truly minimal/microkernel type OS that has a high level of reliability). All application that execute in the environment would work in their own virtual sandbox, which may contain an entire OS emulation, or simply the basics to execute - or in other words virtual containers. These applications would interact with the GUI via the window manager, and negotiate the layout within the systems capabilities. The Virtual Container would execute either locally, on a server, or in the network/cloud based upon the negotiated policies and client device capabilities. For containers executing locally, differences of the container would be archived and ready for use on other machines or as backup (depending on connectivity, etc).
The key here is an environment that from the base up is built with device capabilities in mind - if you're executing a spreadsheet calculation and your device is going to take days to calculate it, have another location process that for you. If you're using the same data as everyone else, make one image of it in the community of users, and everyone works from that image - when the image is upgraded, everyone migrates over time. If the device has Intel vPro capabilities, the virtual containers and dial-ton OS can take advantage of the energy-efficient performance, manageability, and security features. If the device is ATOM based, then a whole new set of features are exposed. Etc... (I had to add in my own Intel fanboy comments, but comments I really believe in).
The road to get from here to there involves a ton of non-trivial solutions, and I believe the good news is that many of the solutions are being thought about by some great minds - however I am sure there are some new and exciting "change the world" ideas left to solve...
The future looks both responsive and reliable, and environment where we are not encumbered by the limitations of our environment, but simply a click away from doing our next task.
-Jason Davidson