IT professionals may wear many hats in their organizations, but we tend not to be known for our fashion sense.  To assist in that area, I’d like to cover one of the latest styles in virtualization: The return of the thin client.  Case in point: see Alex Barrett’s coverage of HP’s acquisition of thin-client vendor Neoware, Inc: Virtualization informs HP’s Neoware Acquisition.  It’s time for traditional fat desktops to start becoming even more self-conscious.  Of course, thin clients never really went away - they’ve been around since the popularitzation of the ”network computing”, which started in the late 90’s.  Lest any of you commit a social faux paus while strutting down your data center’s loading ramps, I wanted to point out some of the issues that prevented the predicted takeover of thin clients:

• Cheaper desktops:  Reducing hardware acquisition costs were a goal for thin client proponents.  As desktop computers hit the sub-$500 range, however, the cost advantages of using thin client computers became far harder to justfiy. 
• Fatter apps and OS’s: A while ago, I heard someone ask the most pertinent question I’d heard in years: “Is hardware getting faster faster than software is getting slower?”  The answer, my friends, seems to be “no”.  As hardware gets more capacity, OS’s and applications tend to swallow it up like a supermodel at a salad bar.
• Single points of failure:  Thin clients (and their users) rely on centralized servers and the network that allows access to them.  Failures in these areas mean major downtime for many users. 
• The Application Experience:  Remote desktop protocols could provide a basic user experience for the types of people that use a mouse to click on their password fields when logging on to the computer.  Single-task users adapted well to this model.  But what about the rest of us?  I’d like the ability to run 3-D apps and use all of my keyboard shortcuts.  And, I’d like to be able to use USB devices such as scanners and music players.
• Server-side issues:  Server-side platforms from Citrix, Microsoft, and other vendors had limitations on certain functionality (such as printing). 

So, is it possible for these super-skinny client computers to address these issues?  I certainly think it’s possible.  Server and network reliability has improved over the years, forming a good basis for reliability.  Thin clients are inexpensive, and server-side hardware and software has improved in usability features.  For example, Windows Server 2008’s Terminal Services feature provides the ability to run specific applications (rather than the entire desktop) using a remote connection.  And, multi-core processors that support large amounts of RAM help enable scalability.  Overall, thin clients are cheap dates, they’re more readily avaialble, and they’re less needy than in the past.  What IT admin wouldn’t like that?  Only time will tell if this relationship will last.

Oh, and one last fashion tip: Don’t throw away your old fat clients just yet.  Like so many other fads, they may be back in style sooner than you think.  Order a slice of cheesecake and think about that!

The big news today is that the Hypervisor for Windows Server Longhorn (codenamed Viridian) is being delayed.  See the Windows Server Division Blog for the main details.  On the surface it seems like this is bad news.  Many of us would like to move to the new Hypervisor ASAP.  From a strategic standpoint, I think it’s most important for Microsoft to ship a rock-solid first version of the Longhorn Server Hypervisor.  So is Microsoft doing the right thing?

When I first heard about the goals for Viridian (which were then pretty closely guarded), I thought that this “feature” was enough to warrant a new release the Windows Server platform (post-Longhorn Server).  At the very least, it could have commanded a “Virtualization Edition” of the product.  It’s no small architectural task to provide for the dynamic addition of hardware, support for large parallel processing, dozens of VMs, etc.  Goals include the ability to easily transition from at least Microsoft Virtual Server (and, perhaps, competing solutions - the names of which may or may not begin with the letters “V” or “X”).  And, it’s a new product - this isn’t a rebranding of another platform.

Microsoft states that scalability (and related testing) is a major reason for the delays.  Given that quality (measuring by reliability, stability, performance, etc.) is not up for compromise, I would have preferred to see Microsoft do a smaller initial release of the Hypervisor.  Perhaps an initial “lite” version that focused on the architecture of the product would have been a better approach.  While running on 64-CPU machines is definitely a plus, I’d rather have a more scaled-down version of the Hypervisor available earlier.  That would allow for determining migration paths, better understanding capacity planning, and for performing initial testing.  With that available, Microsoft could then focus on scalability to very large environments.

Regardless of the release timing, I think we’ll all eventually look back and say that Viridian was worth the wait.  Until then, we’ll have to rely on the many first- and third-party products that are available today.