Wednesday, July 22, 2009

Microsoft Embraces Linux Virtual Appliances

In a very savvy move aimed at gaining competitive advantage in the cloud computing space, Microsoft yesterday announced that they were contributing source code to the Linux kernel in order to optimize the performance and management of virtual appliances on Microsoft's hypervisor, Hyper-V. One of the goals of cloud computing is elasticity – applications scale up and down based upon the hour by hour demand for the application. Well, you cannot have hour by hour elasticity for an application when it takes days/weeks/months to install, provision, and instrument the application onto the infrastructure. Virtual appliances eliminate this challenge by allowing the application owner to pre-configure the application as a set of virtual machines that are ready to respond to demand. The “set-up” is done “off-line.” Microsoft, realizing that Linux is the de facto underpinning for virtual appliances that run on Amazon's EC2, is now contributing code to Linux that will optimize the performance and management characteristics of Linux-based virtual appliances on Hyper-V – the virtualization technology that underpins Microsoft's Azure cloud.

Microsoft's new status as a Linux kernel contributor sheds light on the amazing shift that is occurring in the battle-lines for IT infrastructure. The operating system is going to split, with one half becoming the control software for the hardware (the hypervisor) and the other becoming the control software for the application (virtual appliances). Given their huge advantage with developers based upon the installed base of applications that run on Microsoft-only application frameworks (.Net, etc.), Microsoft has determined that they need to pull out all of the stops in order to be certain they do not get ripped off the hardware in favor of VMware (the dominant hypervisor) or Xen (the hypervisor that supports Amazon's market leading cloud service). Linux is no longer the biggest threat to Microsoft in the datacenter when datacenters begin embracing a cloud architecture such as Amazon's in order to enable IT-as-a-Service.

If indeed this move enables higher elasticity and simpler management of Linux based virtual appliances that run atop Hyper-V, the competitive pressure might force VMware to follow suite and make their drivers and tools available as source code that is included in the Linux kernel. To be clear, Microsoft does not currently plan to support Linux virtual appliances on Azure, but that position may be shifting with changes of this type. With Amazon currently holding the dominant position in cloud and with VMware holding the dominant position in the datacenter for virtualization, Microsoft might have lots of crafty tricks up its sleeve to re-assert themselves in this new theater of datacenter war where hypervisors and virtual appliances rule the day.

Labels: , , , ,

Monday, August 27, 2007

Symantec Virtual Appliance Stymied by Windows Licensing

Last week Symantec declared that it would delay delivery of its security virtual appliance due to Windows CE licensing restrictions. As part of the announcement, product manager Gary Sabala indicated a desire to “move to more open source components” in order to “ease our ability to work around some of the licensing issues.” Not surprising.

Microsoft has no reason to endorse virtual appliances as an application delivery format because they eliminate the general purpose operating system's value proposition. Also not surprising that Symantec has reached the conclusion that they need more control over the components of a solution that ships as a virtual appliance. Having your product shipments subject to the licensing whims of an erstwhile “partner” is not a good idea.

I could drone on and on (as I typically do) regarding the deficiencies of the general purpose operating system as a platform for virtual appliances, but today I will point you to some of the hits from the past that hammer home this point:

Your Application is Your Avatar – why settle for the limitations imposed on your application by the requirement to connect to a physical server?

Microsoft Attempts Software Appliances – the key word is “attempts,” as the Microsoft packaging approach for the operating system is woefully inadequate due to its general purpose operating system legacy.

Yrtsudni Erawtfos – Putting the operating system first among customer application considerations is the business equivalent of spelling “software industry” backwards.

Microsoft Seeks Pepto-Bismol Patent – Although not yet delivering applications as virtual appliances, they are nonetheless seeking intellectual property that paves the path to the future.

Now it's time to place those sales calls to Intel and Symantec. I think they might be in the market for a real virtual appliance platform. . .

Labels: , , ,

Saturday, June 23, 2007

Microsoft Attempts Software Appliances

Microsoft has been slowly revealing the roles that will be available as Server Core installation options for the upcoming Windows Server 2008. These Server Core installations are effectively Microsoft's attempt to provide a software appliance packaging option for customers in order to address the nightmare of administration and stability issues created by the general purpose OS approach (i.e. “one size fits all”). So how are they doing?

In a recent blog post, Scott Fulton replays some of the messaging that Microsoft product manager Andrew Mason delivered at TechEd 2007. According to Scott's post, Microsoft has achieved the following:

- a reduction in the attack surface of the OS from 5GB to about 1.5GB

- a corresponding reduction in the patching burden of 60%

- command line administration (although without “Powershell” - whatever that is)

- 9 server roles available sometime in 2008 or 2009, including a hypervisor role

Well, I suppose this is progress. However, if the goal is simplicity and a reduction in the burden of administration for security and patching, Microsoft still has a very long road to travel. Let's do a quick comparison with rPath's rBuilder capability:

- attack surface for “group core” is about 50MB (no, that is not a typo)

- by proxy, a reduction in the patching burden of 85% vs. the classic Windows approach (this figure does not consider at all the lesser patch requirement for Linux overall, just a straight ratio)

- command line plus graphical, Internet enabled rPath Appliance Agent administration

- infinite roles available based upon the applications generally available for Linux

As the world adopts server virtualization for X86 en masse, these critical packaging differences are going to become a huge challenge for all of the general purpose OS vendors. When hypervisor virtualization such as that offered by VMware and XenSource replaces the general purpose OS as the mechanism for managing infrastructure and attaching applications to the infrastructure (via virtual appliances), the critical packaging requirements for the OS that hosts applications will be:

- tight dependency management for the smallest possible attack surface

- configuration flexibility to optimize the system software to the application workload

- flexible kernel tooling to optimize performance across the various hypervisor management systems

- user friendly interfaces for creating and maintaining the software appliance definition

Given the technology, business, and cultural hurdles that the incumbent general purpose operating system vendors face in implementing these capabilities, it is unclear to me that they will commit to this new approach in a timely fashion. Although Microsoft acknowledges the need for these “slimmer” server core roles, they only plan to achieve a surface area reduction to 1.5GB, with limited roles, and virtually no user enabled packaging options for further optimization for the variety of applications and hypervisors. If that is all that Microsoft can achieve in the face of this obvious demand in the market for hypervisors with virtual appliances, the relevance of the incumbent players in the OS space may be diminished more quickly than anyone currently imagines.

Labels: , , , , ,

Thursday, March 01, 2007

Licensing Hullabaloo

I love using the word “hullabaloo.” I don't get to use it often, but it is a great word to describe the cacophony of voices currently debating virtualization licensing practices.

It began with a New York Times article by Steve Lohr in which he described the competitive challenge that virtualization (and VMware) poses to Microsoft's operating system business. Then VMware posted a white-paper describing the licensing practices and their potential negative impact on customers. And Microsoft responded with a statement from Mike Neil, the General Manager of virtualization platforms for Microsoft. No doubt the analysts will begin weighing in on the matter soon. Why all the buzz? Why now? Because the impact of virtualization on the software industry promises to be similar to that of the Internet, and everyone wants to find a control point from which to steer their fortunes.

Virtualization is disruptive because it fundamentally changes the relationship between the hardware, the operating system that runs on the hardware, and the applications that run on the operating system. The hypervisor (virtualization platform) becomes the new layer on the hardware, and the operating system simply becomes an extension of the application as part of a software appliance. If the hypervisor becomes the “new” standard operating system, and any application can run on the hypervisor as a software appliance, it stands to reason that Microsoft and the other big operating system vendors such as Red Hat would be threatened by this change because they lose their point of control – how applications get attached to computers.

But what does all this have to do with licensing? Historically, there has been a strong correlation between the number of physical computers owned by a customer and the number of operating system licenses that a customer required. With virtualization, it is conceivable that every application is a software appliance with its own operating system attached. Moreover, these software appliances might come and go on the network based upon demand for the application. For example, a payroll application might run for a couple of days every month, but otherwise, it is not needed. With software appliances, the payroll software appliance would be deployed to a computer (atop the hypervisor) to run during the days before payday, and then be removed from the machine to make room for other applications to run more speedily during the rest of the month. Should the customer pay for a “full time” license to the operating system that is inside the payroll software appliance? Or should they have a “part time” license that more closely reflects the manner in which they use the payroll software appliance?

There is a lot at stake here for Microsoft. If the hypervisor becomes the “full time” operating system on the hardware that enables the “part time” software appliances to arrive and run as needed, Microsoft surely wants that hypervisor to be a Microsoft product, not one from VMware. If the operating system in the software appliances is simply an extension of an application, Microsoft may experience price erosion due to the minimalist nature of the operating system and the “part time” usage scenario.

In any case, Microsoft has a right to license their technology in any manner they see fit, so long as it does not break the law. If the licensing is not in the best interest of customers, customers will vote with their wallets and seek alternatives. Best of all for me, it gives an opportunity to use a great word like “hullabaloo” to describe the ruckus.

Labels: , , , , , ,