Friday, March 26, 2010

(Editorial) Why the Client Hypervisor is Doomed

Big surprise! Both VMware and Citrix have fallen behind schedule in delivering their “bare metal” hypervisors for client computing. Both had promised to deliver solutions by the end of 2009, but now VMware has reset that goal to the end of this year while Citrix has stopped talking about ship dates altogether.

So, what happened? In a word, hardware. Or more precisely, the ever changing cornucopia of PC hardware devices and configurations. A “bare metal” hypervisor has to sit at the very bottom of the software stack, where it directly manages, and controls access to, the underlying hardware devices. And doing those two things requires hardware-specific control software – i.e. device drivers.

Developing a comprehensive library of device drivers is no easy task (just ask Microsoft). Even assuming that you can create enough generic or “pass through” type modules to allow the majority of common devices to function, there will still be the inevitable subset of components or peripherals that refuse to cooperate.

It would only take handful of (highly publicized) customer run-ins with such finicky devices to give the “bare metal” client hypervisor a long term compatibility black-eye. Which is why these leading vendors continue to test – and wait.

But waiting (and testing) won’t solve the long-term problem of PC hardware churn. Unlike in the server space, where hardware evolves more slowly and where there are fewer basic configurations to support, the client PC space is in a constant state of flux. The never ending performance arms race, coupled with a near constant stream of innovation at both the internal and external component level, has turned the PC platform into a moving target. Blink, and you’ve missed it.

What is needed is a layer of hardware-level device abstraction, with groups of discrete components functioning as a logical block and accessible through a relatively static interface model. Intel is doing its best to promote as much through its vPro and similar management initiatives. However, these sorts of solutions require significant buy-in from the very OEM partners who stand to lose by making client computing environments portal across hardware platforms. Why would HP want to make it easier for you to move your stuff over to Dell or Acer?

And then there’s the 800lb gorilla in the room next door. Microsoft, which stands to lose the most in a hardware-abstracted world, has been relatively silent on the issue. Ask them about “bare metal” hypervisors on the client and they’ll respond that they “already have one…it’s called Windows.”

In fact, much of what a “bare metal” hypervisor does is entirely redundant in a Windows client environment. It’s an abstraction (client hypervisor) of an abstraction (the Windows Hardware Abstraction Layer). Which makes me wonder why you would really want one in the first place.

After all, it’s not like the current generation Windows platform is really tied to the underlying hardware. Technologies like Plug & Play and improved hardware auto-detection/driver-reconfiguration have made the process of creating a portable, hardware-abstracted Windows client image relatively trivial. This was the whole point of developing WIM and other post-XP installation technologies: To make PC imaging easier.

So, if the primary goal of a “bare metal” client hypervisor is to further abstract the OS from the hardware (and I give zero credence to the “other” reason being bandied about: Running multiple OS VMs on a single PC), and if this task is already handled quite effectively by Windows and its well-established device driver ecosystem, then the only real reason to pursue such a strategy is if  you’re trying to do an end-run around Microsoft’s desktop hegemony.

Which is exactly what VMware and Citrix (not to mention Microsoft’s fair weather friends at Intel) are trying accomplish. They want to remove the Windows kernel/HAL/driver model as the gatekeeper to the PC client world. As such, their actions represent a clear and present danger to the ongoing survival of Microsoft’s core desktop OS business.

And we all know what happens to companies that post a threat to Microsoft’s bread-and-butter revenue stream. First they pan you. Then they copy you. And, finally, they bury you – typically with one of those infamous “free” solutions that seems to fit the bill but still somehow locks you into their world.

A “bare metal” hypervisor on the desktop? Without Microsoft’s direct support?

Good luck VMware and Citrix…you’re going to need it!



Tuesday, March 23, 2010

(Editorial) Web Developers: Time to Dump Firefox?

As a commercial web developer, I’m constantly on the lookout for new trends in browser adoption and usage. After all, there are only so many hours in a day, and investing time and energy supporting a faltering standard is both frustrating and inefficient. So it was with some hesitation that I approached our latest project: A complete overhaul of the user interface for our commercial metrics analysis portal site, DMS Clarity Suite 10.

I knew from the last go-around that getting our site to render consistently across the leading browser platforms (legacy IE 6/7 and Firefox) was a chore, one involving lots of dynamic tweaks and clever hacks. Now we were planning to expand this list to include several newcomers, including IE 8 (running in “standards compliant” mode) and Google’s Chrome. The thought of testing, tweaking and re-testing each and every page against four or more separate rendering models was enough to make me start breaking out in hives.

Worse, still, was the fact that, with our DMS Clarity 10 release, we weren’t just overhauling the UI. We were gutting the entire site to make way for a new, highly-visual, componentized interaction model. Gone were the static page layouts of the past. In their place, a collection of discrete rendering widgets that would assembled on the fly to create a fully customizable presentation. These widgets could be re-arranged, broken-out into their own windows and re-attached to other parts of the site in order to better identify and expose the most critical data points. Here’s a screenshot of the net result:

image Figure 1 – DMS Clarity 10 Portal Site (BETA)

Not surprisingly, the project ran behind schedule, with much of the delay attributable to us figuring out how to get identical results across our various target platforms. For example, calculating the window resize values for our slide-out widget configuration panel. Each browser had its own idea of how “big” or “small” a window would become when we executed the window.resizeto() method. To short, and you’d cut-off the panel. Too long and you’d end up with lots of ugly white space.

Our workaround was to read the browser make/version via JavaScript and then dynamically resize the underlying ASP.NET panel control prior to rendering the page - not a complicated task, but one that required a lot of trial and error to get the desired result. It definitely qualified as a “hack” solution in my book, though by all accounts its a fairly common one.

image Figure 2 – Clarity 10 Widget Rendering Consistently

Needless to say, we got to know a lot about the various quirks and rendering oddities associated with today’s web browsers. And by far the biggest PITA to work with – next to legacy IE 6/7 - was Firefox. HTML and CSS that would render consistently on IE 8 and Chrome would always require some hand-tuning for Firefox, while JavaScript code that ran flawlessly under the other browsers would often need at least some minor tweaking for Firefox to be happy.

In fact, it got so bad that we eventually had to expand our base template design to include three major potential rendering models: IE legacy, Firefox and “everybody else” (including Chrome and IE 8). And when even those assumptions proved to be inadequate (offset values that worked for one page would sometimes also work elsewhere, but not consistently), we seriously considered dumping Firefox support altogether.

With most of our commercial customers still using IE for in-house application access, it was a shortcut we could probably have gotten away with. However, in the end we decided to bit the bullet and hand-code the necessary markup and scripting corrections. After all, Firefox is still a major web presence, and we do plan to offer Clarity 10 as a hosted commercial solution later this year.

However, the situation was very much “touch-and-go” there for a while. Had we been under tighter time constraints, or if we had run into any real “showstopper” issues that compromised our design in some fundamental way, we likely would have given Firefox the boot.

Compounding matters is the perception, now shared by many of my contemporaries, that Firefox is in decline. Our own exo.repository numbers still show strong (50%) use among our tech-savvy contributor base. However, those same users are also increasingly turning to Google’s Chrome. Some 25% of systems monitored by the report Google’s nascent web browser.

Figure 3 – Latest exo.repository Browser Share Statistics

If this number climbs much higher, and if Firefox use takes the kind of nose-dive so many are now predicting, we may have to revisit our decision to continue supporting Mozilla’s browser. With the web gravitating towards the rapidly maturing webkit, and with the latest versions of IE and Chrome converging towards a consistent rendering result, the writing may finally be on the wall:

Save yourself a headache or two and dump Firefox.