This week, Microsoft set loose “Longhorn” Server Beta 3, and the release is brimming with evidence of the hard work Microsoft has put into polishing the configuration wizards that work to abstract away the knotty details of the applications and services these interfaces front.
Of course, the yellow brick road to the configuration wizard isnt the only or best path to abstracting away complexity. Moving forward, the name of the game in IT abstraction is virtualization, a fact that Microsoft has acknowledged by taking steps to make Longhorn play better both as a guest and a host for server virtualization. Based on this late beta, however, its looking like Longhorn will fall short on its virtualization promises.
Most glaringly, theres the fact that Longhorn is set to ship without the built-in Windows Hypervisor that initially had been slated to bake virtualization right into Windows Server.
I think that Microsoft wouldve done better to have built the open-source Xen hypervisor into Windows rather than to have built its own hypervisor. It seems that since the Xen hypervisor sits in its own layer below its guest instances, Microsoft couldve shipped that GNU GPL (General Public License) component while maintaining proprietary licensing for the rest of its operating system.
Granted, building your own hypervisor is a hefty task, and Im ready to accept for now that Microsoft has good reason to chart its own course here, even if that means lagging behind its server OS rivals with integrated virtualization support. Whats more puzzling, though, are the holes in Microsofts strategies for making Longhorn Server a better virtualization guest.
One of Longhorns long-expected new features is support for deploying the OS in trimmed down “core” configurations that will reduce overhead and attack surface by leaving out superfluous code.
Why, for instance, should you have to tell Windows Server not to worry about updating to an Internet Explorer 7 revision that youll never be running on that machine anyway? These lower-overhead configurations are particularly important for virtualized servers, which spend the bulk of their time running heedlessly.
However, unlike most Linux distributions, for which you can deploy a minimal configuration and then pull in what components you need to support your applications, Longhorn Core supports only a handful of Windows roles, such as those for file services or Active Directory.
As a result, you wont be able to deploy your own applications on Longhorn Core, nor will ISVs be able to use Longhorn Core to deploy thin, Windows-based software appliances.
The relative lack of rigor in Windows software management framework also means that the new command-line version of Longhorns server management tool wont work on Longhorn Core because the tool depends on the .Net Framework, and the .Net Framework depends on too broad a swath of the full-blown Windows OS to run on the server core. Microsofts new command-line interface, PowerShell, wont run on Longhorn Core, either, because PowerShell also depends on the .Net Framework.
The virtual software appliance approaches now being pushed and facilitated by the likes of rPath and its appliance-producing rBuilder platform, VMware and its VMTN (VMware Technology Network), and Amazon.com and its Elastic Compute Cloud stand a solid chance of displacing the OS as a general-purpose platform model to which Windows Server has been designed to conform.
I used to think that licensing represented the biggest roadblock to Microsofts participation in this model, but with the virtualization-friendly changes the company has already made to Windows Server licensing, Microsoft has demonstrated that its willing to adjust its business models to adapt to new virtual realities. However, without technology changes to match its business moves, Microsofts going to have a tough time keeping up with Linux in this space.
Check out eWEEK.coms for Microsoft and Windows news, views and analysis.