Verizon Misses with Cloud Offering

About two weeks back, I was excited to see a headline about Verizon partnering with Red Hat to offer their customers a “new” cloud computing offering. I was hopeful that the details would reveal a KVM hypervisor based elastic compute capability coupled with an OVF based specification for virtual appliances to run on the service. I was also hoping to discover some details on storage as a service, with all of the services accessible via a management capability exposed via RESTful APIs. Boy, was I disappointed. Turns out the new Verizon cloud offering is just the old Verizon hosting offering with a new name.

Why is it so difficult for all of these old school infrastructure providers to understand the new path being blazed by Amazon AWS? Why can't they offer even a reasonable facsimile of the capability provided by Amazon? Surely it is the threat of Amazon that is leading them to re-name the old hosting stuff as the new cloud stuff. Why not go all the way and actually offer something that is competitive? Here is a recipe for any that are interested:

First, provide a X86 hypervisor based, virtualized compute service that allows the customer to bring their applications with them as pre-packaged, pre-configured virtual machines (virtual appliances). Don't ask them to boot a “standard OS” and then spend hours, days, weeks, months configuring it to work for them (because what you specified as the “standard” is certainly not what they have tested with their applications, and the whole purpose of elasticity is defeated if you can't quickly put images to work on the network in response to application demand). Better yet, let them boot existing Amazon Machine Images and VMware virtual appliances. Providing this capability is not rocket science. It is just work.

Second, provide a simple storage service (see Amazon S3 for what it should do) for storing unstructured data as well as for storing their virtual appliances that boot on the virtualized, elastic compute service. If you don't want to take the time to develop your own, follow AT&T's lead and go buy the capability EMC offers as part of the Atmos product line. You don't even have to think, you just need to write a check and viola – an Amazon S3 type capability running on your network. What could be easier?

Third, provide a block storage capability for attaching to virtual appliance images that must store state, such as database images. Most of the hosting companies already provide this type of SAN offering, so this part should be a no-brainer. Just price it with a very fine grained, variable cost approach (think megabyte-days, not months).

Fourth, provide access to the infrastructure management services via simple, RESTful APIs. You don't have to go overboard with capability at first, just make certain the basics are available in a manner that allows the services to be run effectively over the Internet without any funky protocols that are specific to your network implementation.

Finally, go sign up partners like rPath and RightScale to offer the next level of manageability and support for the virtual machines that will run on the network. These are the final touches that indicate to your customers that you are serious about providing a terrific capability for the complete lifecycle of your cloud computing offering. Instead of asking them to be patient with you while you re-name your hosting offering as a cloud offering in the hopes that it will assuage their bitterness that Amazon-like capability is not available on your network.

Red Hat Goes Streaking - Dumps Xen

Yesterday Red Hat announced their revised virtualization strategy. Most interesting to me was Red Hat's declaration that the hypervisor should indeed lie "naked" on the metal. Red Hat also announced end-of-life for Xen support and some stuff regarding desktop virtualization and protocols that I don't pretend to understand. While it was expected that Red Hat would end-of-life support for Xen after their acquisition of the KVM technology from Qumranet, the fact that Red Hat went streaking into the market with a bare metal approach to the hypervisor was a pretty significant strategy reversal.

Until yesterday, Red Hat had always adopted the Microsoft line on the hypervisor - it is simply a feature of a general purpose operating system. Red Hat historically claimed that the hypervisor should not lie naked on the bare metal, but instead it should be wrapped up inside the general purpose OS - a little extra bloating that never hurt anybody. It looks like some combination of market forces - likely VMware financial success and Amazon's adoption of Xen for their Elastic Compute Cloud - have forced Red Hat to consider a new approach. Now Microsoft stands alone in their contention that a hypervisor is just a new general purpose OS feature, and the rest of the market can move on to the market share land grab for the large-scale Linux datacenters. It should be an interesting race, because all three players - Xen (Citrix), KVM (Red Hat), and VI (VMware) are all coming from different positions of strength - and weakness.

In almost every case I have observed, Xen is the incumbent virtualization technology among the Linux datacenter consumers that have virtualized any production workloads. However, not many have actually virtualized because the historical compelling case for virtualization - server consolidation - falls on deaf ears among the Linux crowd. With Linux, as opposed to Windows, it is possible to run multiple application workloads on a single server without significant instability. Server utilization can be quite high without virtualization - hence no requirement for Linux server consolidation. But, the new benefits of virtualization - flexibility, security, and elasticity - apply equally, if not especially, well to the Linux workloads. If application workloads are separated into unique, small footprint, virtual machines (virtual appliances, if you like) that run atop a bare naked hypervisor, then:

- flexibility is better because one application can be managed/administered without interfering with another workload running on the same host

- security is better because vulnerable services like DNS are isolated and easier to maintain/secure due to a smaller footprint

- elasticity is better because application workloads can be scaled quickly when demand increases and also retired quickly when demand recedes (cloud, anyone?)

Because of these new business benefits, Xen is beginning to take hold in the Linux datacenters. Citrix, however, has not historically been a strong brand among the Linux savvy crowd, so it is unclear if they have the stomach for pursuing a new market segment. VMware is the 800 pound gorilla in hypervisors generally, but they too have shown very little Linux savvy (their management console only runs on Windows) - probably because 90% of their revenues come from virtualizing Windows workloads. Then there is Red Hat, the 800 pound Linux gorilla who has been in denial about the importance of a bare metal approach for the hypervisor - until now.

Based on this set of circumstances, I would say that the virtualization opportunity for the Linux datacenter market is a wide open race. Now that Red Hat has decided to run the race naked, it should be more fun to watch.

VMware Strikes Back

The tech industry has been all abuzz lately about the competitive hullabaloo surrounding the new hypervisor technologies that are emerging to take on VMware's dominant hypervisor product. Microsoft launched Hyper-V with a party last week to upstage VMware's VMworld event this week. Red Hat purchased Qumranet to solidify its control of the KVM hypervisor technology. Now, VMware is striking back at the legacy OS vendors by labeling their new product category the Virtual Datacenter Operating System – a direct attack on the entrenched category of the general purpose operating system. The cold war of spies and covert operations to grab mindshare while outwardly promoting a message of peaceful co-existence has officially escalated to a hot war for the future architecture of the datacenter.

I, for one, am happy to see this rise in hostilities because I believe it will carry the industry to a much better place – and customers will be the primary beneficiary of the new approach. In the legacy datacenter, a general purpose operating system attempts to serve both the hardware infrastructure with device drivers while also serving the applications with system services. This approach has the disadvantage of artificially coupling applications to physical servers. Any attempt to move the application to another physical server typically requires that the configuration and validation process begin anew because it is extremely unlikely that the new server is absolutely identical to the previous one. This lack of flexibility leads to extreme overspending on capital equipment because an application with a period of low demand cannot relinquish its hardware resources to an application experiencing high demand. The hardware resources become application specific, and each application owner must size hardware capacity to meet peak demand. Server utilization in the datacenter averages 15 – 20%, and the general purpose OS is the culprit.

VMware has now declared that they offer an alternative approach to the general purpose operating system. The technology is not new, but marketing it under the category of an operating system is a very different tactic in this war for the datacenter. The conflict is now overt instead of covert, and this change was inevitable as VMware attempts to expand its footprint beyond its bread and butter business of Windows server consolidation and test lab operations. The new objective is the elastic datacenter and ultimately cloud computing.

The datacenter becomes elastic when applications are released by developers as coordinated sets of virtual machines (or virtual appliances in the case of a vendor release), each with Just Enough Operating System (JeOS or “juice”) attached to provide the system services required by the application. These applications can expand or contract on-demand because there is no onerous configuration process to ready the general purpose OS for a specific application. Instead, the hypervisor accepts the virtual machine and allocates it resources as specified by the OVF meta-data that is included with the image. Applications are up and running in a matter of seconds, and the process is totally repeatable to assure stability, security, and compliance as workloads scale, de-scale, and re-scale to meet the ever changing demand profiles of the enterprise application portfolio. Infrastructure can become a variable cost via this architecture because the scaling cycle can include hardware resources provided by third parties via a hypervisor layer – aka cloud computing as popularized by Amazon's Elastic Compute Cloud (EC2) via the Xen hypervisor.

The reason I label this new competitive tact by VMware as “warfare” is because the concept of a hypervisor as the infrastructure management layer with JeOS as the system services layer for the applications delivered as virtual machines destroys the value of the general purpose OS. If a hypervisor provides access to the infrastructure via device drivers, and applications receive system services from JeOS, and the flexibility of the datacenter improves, and the management of applications is simplified, and I can embrace cloud computing for variable cost infrastructure, why would I ever again buy a general purpose operating system? I won't. And customers won't either.

Unleash the dogs of war. Let's get to it so that we can all live happily ever after on the other side of history.

Shut Down the Datacenter

Or at least power down significant pieces of it during periods of low demand. This message always draws funny looks from IT types when I suggest a seemingly simple answer to the problem of extreme costs for datacenter resources. I push on:

Billy – If utilization is around 20 – 30%, aren't there periods of time when you could just shut down about 50% of the systems? Or at least 25%?

IT – We can't just shut the systems down. . .

Billy – Why not? You aren't using them.

IT – You don't understand.

Billy – What am I missing?

IT – Well, it just doesn't work that way.

Billy – How does it work?

IT – It takes a long time to lay the application down atop a production server.

Billy – Why?

IT – Set up is complicated. Laying down the application and bringing it online can take several days, typically 2 to 4 weeks.

Billy – So part of the application definition is described by the physical system it runs on?

IT – Yes, that's right. If I shut down the physical system, I lose part of the definition and configuration of the application.

And therein lies the culprit. The “last mile” of application release engineering and deployment is a black art. Applications become tightly coupled to the physical hosts upon which they are deployed, and the physical hosts cannot be powered down without losing the definition of a stable application. Bringing the application back up is expensive due to the high costs of expert administration resources, and it is fraught with peril because the process is not repeatable. Enterprises are spending billions of dollars on datacenter operating costs because the risk of bring applications back on-line is not worth the savings of taking them off-line.

Of course I blame most of this mess on the faulty architecture of the One Size Fits All General Purpose Operating System (OSFAGPOS). OSFAGPOS is typically deployed in unison with the physical hosts because OSFAGPOS provides the drivers that enable the applications to access the hardware resources. To get an application to run correctly on OSFAGPOS, the system administrators then need to “fiddle with it” to adjust it to the needs of any given application. This “fiddling” is where things run amok. It's hard to document “fiddling,” and it is therefore difficult to repeat “fiddling.” The “fiddle” period can last for up to 30 days, depending on the complexity of the “fiddling” required.

So how do we get away from all of this “fiddling” around, and deploy an architecture that allows the datacenter to scale up and down based on actual demand? Start with a bare metal hypervisor as the layer that provides access to the hardware. Then extend release engineering discipline to include the OS by releasing applications as virtual machines with Just Enough OS (JeOS or “juice”) in lieu of OSFAGPOS, complete with all of the “metadata” required to access the appropriate resources (memory, CPU, data, network, authentication services, etc.). By decoupling the definition of the application from the physical hosts, a world of flexibility becomes possible for datacenter resources. Starting up applications becomes fast, cheap, and reliable. As an added bonus, embracing cloud capacity such as that provided by Amazon's EC2 becomes a reality. Instead of standing up application capacity in-house, certain peak demand workloads can be deployed “on-demand” with a variable cost model (in the case of Amazon it starts at about $.10/CPU/hr).

With oil trading at around $140 per barrel, the cost of allowing datacenter resources to “idle” during slow demand periods is becoming a real burden. “Fiddling around” with applications to get them deployed on OSFAGPOS is no longer just good clean fun for system administrators. It is serious money.

Red Hat oVirt(ly) targets VMware and Citrix

Red Hat announced last week that they are developing technology that will one day become a product to challenge the offerings from VMware and Citrix. The technology is showcased at a website sponsored and maintained by Red Hat as part of an “emerging technology” initiative. Aside from the fact that Red Hat is announcing technology projects and not products, the most noteworthy detail of this approach is the emergence of KVM (kernel-based virtual machine) as the hypervisor approach that Red Hat intends to back. Taking a page from the Microsoft HyperV playbook, Red Hat is claiming virtualization as a “feature” of the OS they already control in order to maintain their investment in the server distribution channel they have established with OEMs such as Dell, HP, IBM, Fujitsu, and others. Bare metal hypervisors and their associated infrastructure management frameworks are threatening the entrenched status quo of the operating system vendors, and Red Hat does not intend to “go gentle into that good night.”

Historically, a general purpose operating system performed two key functions: 1) provide drivers so that applications can access the hardware, and 2) provide system services (file system, libraries, etc.) to the applications. The trouble with this approach is that applications become artificially coupled to the hardware. Have you ever experienced pain upgrading hardware when the application that ran just fine on the old hardware no longer runs on the new hardware because of changes in the operating system? Do you find that you are continuously porting and testing applications just to upgrade hardware? Why? Because a one-size-fits-all general purpose operating system (OSFAGPOS) couples hardware support with application support due to the architecture of the product. Aside from the application portability issues, the OSFAGPOS approach also leads to the enormous management cost associated with bloating. Most applications run atop an operating system in the datacenter that is 10X the size actually required by the application, which leads to a patching nightmare.

To be fair to Red Hat, KVM could certainly be implemented and maintained by them as a skinny bare-metal hypervisor that only concerns itself with managing the hardware infrastructure. The Linux kernel is a fine provider of hardware support, and Red Hat has more Linux kernel expertise than any other vendor in the world. Their technical credibility in this space is terrific. The trick will be the marketing challenge of offering a product that has a very different value proposition than the OSFAGPOS. The goal of a bare-metal hypervisor is to support as many application OS variants as possible in order to enable application providers to choose the system software that works best for their application. This flexibility for the application flies in the face of the OSFAGPOS argument to “standardize” the OS to gain economies of scale in management and support. With OSFAGPOS, at least you know what systems need to be patched – all of them . . . all the time. Embracing a bare-metal product approach would mean that Red Hat also needs to face up to OSFAGPOS management challenges and embrace virtual appliance value for applications that run with Just enough OS (JeOS or "juice") optimized for their workload.

I believe that the separation of the duties of the historic OSFAGPOS architecture into two separate product domains - hypervisors for drivers and JeOS for application support - is inevitable. Separating hardware support from application support simply provides too many benefits. The popularity of both VMware and Amazon's emerging EC2 service are great examples. Watching both Red Hat and Microsoft navigate this change will be interesting. The marketing gurus at both companies will be strained to the breaking point as they “rage, rage, against the dying of the light.”

EMC means Even More Clouds

Last week, Doug Merritt, an executive vice president at SAP, informed Information Week that EMC is planning to offer a computing utility service suitable for running enterprise applications. This “cloud” (a term popularized by Amazon's Elastic Compute Cloud) would offer SAP an ability to deliver on-demand applications to enterprise customers without investing the significant fixed costs of large scale datacenters ala Salesforce.com. The cloud capability is likely to make heavy use of the VMware hypervisor technology owned by EMC (Amazon uses the competing technology called Xen) such that providers like SAP can define their applications as virtual appliances (or a set of virtual appliances, known as a virtual appliance network or VAN) and launch them on-demand into the cloud. ISVs such as KnowledgeTree are already doing this using virtual appliances and Amazon's cloud. Why not SAP with an EMC cloud? What is the likely scenario for enterprise adoption?

As enterprise customers increasingly virtualize their datacenter computing resources, it is going to become more and more common for them to rely on computing clouds outside of their datacenter for certain application workloads. Once you have virtualized the infrastructure and defined the applications you run as virtual appliances (i.e. they are defined independent of the computer that they run upon and are loaded on the virtualized infrastructure pre-configured with the OS), moving the application from datacenter to datacenter (or cloud to cloud) becomes much easier.

Rather than buying all the servers required to deliver the application at peak load, it makes more sense to launch new instances in the cloud during peak demand and pay a variable cost charge until the peak subsides. Similarly, batch oriented analysis that occurs once per day/week/month (perhaps closing the books and logging transactions at the end of a month) is an ideal application scenario for cloud computing with virtual appliances. Why own the servers when you only use them periodically? Is it becoming clearer why SAP and EMC might be collaborating on this type of service? It's pretty clear to me.

But what's missing? Why is this obvious scenario not already mainstream? To begin with, production implementation of virtual infrastructure is only now beginning to take hold. Historically, virtualization was used extensively in test and development or to curb Windows server sprawl (a condition that occurs because Windows cannot effectively host more than one application per OS instance). Now, enterprises are beginning to understand that virtualizing every application makes sense because it separates the evolution and maintenance of the application from the evolution of the hardware infrastructure.

For example, it makes much more sense to create a virtual appliance for an existing single-threaded application and run several instances on a dual socket, quad-core eight way machine than to attempt to re-write the application to take advantage of the quad-core threading model. There is no value in the re-write, and virtualization provides a means to scale the application to take advantage of modern hardware. Another obvious benefit of this separation of application and hardware is server maintenance. You can shutdown one virtual appliance to patch it and then spin it back up without disturbing any of the other virtual appliances running on that server. This approach minimizes application to OS conflicts, and it eliminates application to application conflicts.

If virtualized production infrastructure is a cloud requirement that is slowly becoming a reality, what other obstacles lay on the path to cloud nirvana? Well, the current most popular approach for virtualizing applications is building a working system from legacy components and then “snapshotting” it with your favorite physical to virtual (P2V) tool. This approach will not scale to cloud computing. First, it is unlikely that your cloud provider has a virtualized infrastructure that is identical to your own. Going through a manual, ad-hoc process to build snapshot images for each cloud is going to be slow, expensive, and prone to errors. Also, it is inevitable that cheap, variable cost computing is going to tempt enterprises to define ever increasing numbers of application images. However, the administration and maintenance burden of the legacy OS system layer is going to result in skyrocketing administration costs or a “don't patch it and hope for the best” security scenario. A new approach to system software that couples the application with just enough OS is a requirement to make cloud computing a scalable reality without untenable administration costs or security risks.

Finally, and perhaps most importantly, there needs to be some “context” language by which networks of virtual appliances communicate to the cloud their requirements for system resources, configuration, and service level. How does an application server communicate to the cloud to boot it on the same network segment as the database server it requires? How does a critical application that is CPU intensive communicate a requirement for 2 CPUs and 4 gigabytes of RAM? How do redundant application servers communicate a requirement to run on separate physical servers to preserve a failsafe capability?

An application architecture for cloud computing will take into consideration all of these current deficiencies. The application and all of its associated context information will be defined as virtual appliances and virtual appliance networks independent from the physical infrastructure. The general purpose OS will give way to a just enough OS approach to enable a more simple and scalable maintenance model. And there will emerge cloud release and service brokering systems for launching applications into the clouds at acceptable service level without error prone manual processes and extraordinary administration expenses. These changes are coming. What are you doing to get your enterprise on the path to cloud computing?

Hypervisor Certification Crossroads

My last blog post, Certification “aka Some Assembly Required,” stirred up an interesting brew of fan mail. It seems that I wrote what lots of people have been thinking when I proclaimed that certification is a weak promise at best -- a hoax at worst -- with most customers spending 6X their license costs on installation, maintenance, and administration of “certified” software. The pity of this whole situation is that software vendors are also paying a high price for the myriad of customer preferences regarding middleware and operating systems. And the price is about to get a lot steeper.

Applications vendors will soon find themselves at a crossroads. They must either embrace virtual appliances (with certification to the hypervisors as the critical element), embrace SaaS ala Salesforce.com as their only distribution approach (where customers get no choices regarding infrastructure or even features for that matter), or brace for an enormous expense uptick in certification costs when they must begin including all of the hypervisor products as additional customer preference items required for testing.

The certification gauntlet that application vendors have historically run in order to deliver their application to the widest possible market is often referred to as “the matrix of pain.” For every element in the stack that might be a customer preference – OS, application server, web server, database – and for every release of these elements, the application vendor creates a row and a column. Each intersecting cell above the diagonal represents a configuration to be tested as part of the R&D expense associated with release engineering. Of course the testing never occurs in the exact configuration of elements for a given customer situation, but some testing is better than none.

And, theoretically, each maintenance update of each element requires re-testing. Of course, no application vendor actually does this testing because they simply cannot afford to do it. As it is, certification gobbles up 40 – 50% of R&D expenditures (not to mention the customer service burden associated with customer variability). Don't believe me? Why do you suppose salesforce.com spends 8 – 9% of revenue on R&D for a pretty rich CRM application when most software companies spend 15 – 18%? Salesforce.com only certifies to ONE infrastructure – their own datacenter infrastructure. And they bring every customer along with every release of software so they do not have the testing expense associated with maintaining legacy code on new platforms or vice versa.

Now, with hypervisors providing customers with so much value and flexibility as the layer that abstracts the hardware from the application, vendors are going to be pushed by their customers to certify their applications against all of the popular hypervisors. And, with such a hot category, there will be lots of technology development and lots of releases. That means lots of NEW columns and rows for the “matrix of pain.” If you thought 40 – 50% of your R&D budget was painful because it sucked the wind out of new feature development, wait until that number climbs to 60 – 70% when you throw in another layer for the hypervisor. Add some more to those costs when customers start demanding that you also support Amazon's EC2 and other similar services like IBM's Blue Cloud.

Had enough? Ready to cry “UNCLE?” Better get busy figuring out how to deliver your application as a virtual appliance. For those virtual appliances, you will STILL need to release and test against the hypervisor products -- VMware, Citrix' XenSource, Microsoft's pending Hyper-V -- along with all of the “cloud” computing services that are going to emerge to compete with Amazon's EC2. Better choose your virtual appliance infrastructure provider wisely to accommodate these customer choices in the market (shameless plug for rPath).

No doubt customers will initially object to some limitation of choice regarding the elements that support the application when you wrap it all up and deliver it with a bow on top as a virtual appliance, but these are the same customers that are going to drive you to embrace hypervisors in your testing matrix. Give them a tradeoff – virtual appliances that are cheap and easy to install, maintain, and administer, or the old fashioned way with a $250,000 per year support uplift to cover your expense for navigating their “matrix of pain.” Standing at this expense crossroads, I bet they make the same decision you should make as you stand at the hypervisor certification crossroads today -- “Let's give that virtual appliance a try.”

Intel Invests Heavily in the Future of Operating Systems - VMware

Intel and VMware announced today that Intel Capital is making a $218M pre-IPO investment in VMware. This investment would give Intel a 2.5% ownership stake in VMware, with a board seat, but no real voting rights whatsoever (less than 1%) relative to VMware's parent company, EMC. So why might Intel be making such a significant investment in VMware? I believe it is because Intel plans to influence the outcome of the investment through its X86 distribution chain.

Sales of computers, especially server computers, are currently constrained by the complexity of software. Larry Ellison estimates that for every $1 in license spending for applications customers spend $6 in integration and maintenance expense. Not only is this complexity a drag on new license sales of software, it is also a drag on new sales of servers to run that software. What if a technology existed that could eliminate the drag of integration and maintenance such that customers could spend more money on new applications and servers? Maybe Intel would be interested in seeing such a technology proliferate?

Well, VMware has that technology, and I believe Intel plans to integrate VMware's technology with it's chipsets such that applications can arrive as virtual appliances, attach to the system in a matter of seconds, and then be managed by the application provider as a complete system image instead of being managed by the customer as a set of “lincoln logs” to be assembled in a unique manner each time. With VMware hypervisor technology as the replacement for the bloated, “one size fits all” general purpose operating system, customers can actually take advantage of Moore's law instead of being held back by the lack of installability, maintainability, and portability of software applications.

How many times has the hardware sales rep been stymied in the sale of a hot new machine because the customer absolutely refused to touch the machine that was currently running their ERP/CRM/SCM/(pick your alphabet soup) application? They refused to touch it because once it was installed, configured, and stabilized no one wanted to repeat the hellish process that led to that stability.

Imagine the new world order with the hypervisor embedded at the chipset level as the replacement for the bloated general purpose operating system. You simply hook up power and networking to the new box, and then “vmotion” the system image on the old box over to the new box. And magically you now have X% more processing power, I/O, memory, or whatever you need on that fancy new box. Life doesn't get much better than that for a hardware sales guy or gal.

My bet is that you see Intel pushing their downstream server partners to adopt Intel chipsets that enable VMware hypervisor functionality at the level of the BIOS. Intel and its downstream partners such as IBM, Dell, and HP will develop system management technology along with vendors like Cisco, Symantec, and McAfee that enables “value added” services to also be delivered to the machine without the general purpose operating system getting in their way. You will see these supply chain partners develop virtual appliance catalogs that contain applications that can be added to the system in the same manner that you add songs to your iPod through iTunes. When software ceases to be a drag due to operating system complexity, hardware sales accelerate tremendously. All this for a measly investment of $218M. I think Intel got a great deal.

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.

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.