BEA Delivers Software Appliance Platform

Last week in Beijing, BEA announced that it intends to deliver a platform for running software appliances atop VMware's virtualization technology. The software appliance approach eliminates the hassles of maintaining a general purpose operating system, and when coupled with virtualization, virtual appliances are delivered pre-configured and ready to run on the hypervisor.

For any application that is 100% pure Java, BEA's Liquid VM provides a great way for an application vendor or application developer to deliver an application from test straight to production without worrying about incompatibilities or conflicts with the operating system. The company claims a reduction in deployment time from 45 minutes to mere seconds. Performance is also supposed to be significantly higher.

It is likely that both of these claims are absolutely correct. Virtualization offers the possibility of streamlining the deployment and management of applications by eliminating the general purpose operating system. When coupled with the hardware acceleration in the latest chipsets from Intel and AMD, virtual appliances should also run faster than native applications because much of the baggage of the general purpose OS is eliminated. And given that there are fewer components and services loaded into memory, virtual appliances should also consume far fewer system resources.

BEA's announcement is one more proof point that higher server utilization was just the beginning of the benefits of server virtualization, and the best is yet to come.

Support is NOT a Software Business Model

I shudder every time I read a blog post or article by some “expert” that proclaims that open source is a “business model” predicated on providing customers “good support” and that open source is fundamentally different from proprietary software. Hogwash.

Open source is not a business model, it is a development model. The software business, open source or not, is about providing customers with a product that is better than the competing product. This concept is fundamental to business, and yet somehow a bunch of young software companies have it in their head that there is something new and magical about open source that exempts it from this fundamental truth. Maybe that is why there is only one successful software company underpinned by open source -- Red Hat. And if you look at the financials of Red Hat, it looks like a great software company, period. No “open source” modifier required.

Let’s do a quiz for the “experts” and see how much they really understand about building a great software company based on open source:

Who spends more money as a percent of revenue on “support and service”? Oracle or Red Hat? It has to be Red Hat, right? They are all about “support and service.” Wrong. Oracle spends 23% of revenue to “service” the customer while Red Hat spends only 18%. I guess open source isn’t necessarily just about selling “support and service” after all.

Who spends more money on engineering their product as a percent of revenue? Oracle or Red Hat? It has to be Oracle, right? Red Hat gets so much R&D leverage from the community. Wrong. Red Hat spends 15% of revenue on R&D while Oracle spends only 13%. I guess customers want more than just a download re-direct from redhat.com to kernel.org.

Who spends more money on sales as a percent of revenue? Oracle or Red Hat? It has to be Oracle, right? Selling really expensive proprietary software has to cost more than selling open source. Wrong. Red Hat spends 47% of revenue on SG&A while Oracle spends 25%. I guess there must be more to selling “free software” than putting up a download site and setting up a PO Box to collect the checks that roll in to turn on support.

A great software business is a great software business, independent of open source. Furthermore, customers will pay a premium for great software, if they cannot get the same great software cheaper from somewhere else. Therefore, if you have a great software business based upon high performing software that is only available from you, there is little reason to open source your product. The corollary – if you have a non-existent software business or mediocre software that cannot command a premium, you are probably a candidate for open source. This basic truth could sink open source software as a category because so many young companies are using the term “open source” like a badge of honor without paying any attention to the fundamentals of the software business.

Red Hat and Oracle are BOTH great software businesses because they invest in engineering and sales in order to deliver a premium product to their customers. Support is a bad business model for software because it misaligns the customer and the vendor. Customers don’t want to pay for support or services, they want software that works WITHOUT support. Vendors that generate revenue from support only scale their business if the software is buggy and difficult to configure – driving support calls/incidents/whatever in order to scale revenue.

The biggest problem I had while running sales for Red Hat was overcoming the customer objection that Red Hat’s software should be very cheap, or that Red Hat’s value should be based upon how much “support” the customer consumed (incidents, callers, whatever). I responded by banning the term “support” from the sales lexicon, setting high quotas and demanding million dollar deals, and requiring the reps to sell on the value of solving a difficult problem – providing Unix functionality on industry standard hardware with a 10X price performance advantage. Additionally, Red Hat moved to the RHEL model where the enterprise product was only available if you agreed to pay a premium for it.

Guess what happened? We sold the value of 10X price performance vs. Unix, and the reps took down million dollar deals and made their big quota numbers and then some. Customers stopped talking about “support” and “free software” because we convinced them that engineering is what really matters . . . . and they could only have the product if they paid for it. If you want to be successful in the software industry, go and do likewise.

Your Application is Your Avatar

Given that “higher system utilization” is the most commonly cited server virtualization benefit, does anyone other than me find it funny that none of the benefit language surrounding Second Life relates to “utilization.” Why is it that we do not hear about the unleashing of formerly idle cycles when one enters the virtual world of Second Life? Why is no one talking about the greater level of productivity achieved when they are able to lead several parallel lives in the virtual world? Is it simply that the business value of computer servers is far removed from the fantasy value of avatars? Or is there something that the server virtualization industry can learn from the popularity of Second Life that will inspire a higher bar for value than the pragmatic, but boring, benefit of “utilization?”

In a recent interview with Zdnet’s Dan Farber, Mendel Rosenblum, chief scientist and founder of VMware, hypothesized the following:

“The biggest misconception [about server virtualization value] is server consolidation [i.e. higher system utilization]. It was the first big application in the enterprise. Part of the problem with being the first successful application is that it misses a lot of the benefits. A virtualization layer is a different way of thinking about hardware, and server consolidation is just one tiny sliver of it.”

I believe Mendel is correct, and I believe we can take a lesson from Second Life to provoke new thinking about what we ought to be attempting to achieve with server virtualization.

In my opinion, the popularity of Second Life stems from the freedom and creativity that is possible when the collective constraints of physical and social boundaries are left at the threshold of the virtual world. Second Life residents are only constrained by their ability to project their imagination into their avatar and their environment, and their ability to represent that projection to others in the virtual world. If freedom and creativity are the dual engines powering Second Life’s popularity, when will these benefits begin to be realized through server virtualization?

The reason that freedom and creativity are not yet the force behind server virtualization is because developers are currently dragging all of the baggage of the legacy world into their virtual machines. How popular would Second Life be if the first step in building an avatar was to do a full and exact body, social, and intellect scan of the player in order to project that exact image into the avatar? And all of the rules and environment of the game were exactly the same as the rules and environment of the physical world? It doesn’t take a genius to figure out that Second Life would be a colossal flop if these were the ground rules. It’s time that developers took charge of their applications in the virtual world and leave the constraints of the legacy server world at the threshold of the virtual environment.

The first step is to get rid of the bloated, general purpose operating system. If you are a developer, your application is your avatar. Its characteristics are unique to the purpose you are attempting to serve with its existence. Its libraries, system functions, and resources should be uniquely crafted to fulfill its mission, without regard for the libraries and functions used by the avatar next door. In the virtual world, your avatar can live side by side with vastly different avatars with never a worry about a server crash associated with conflicts over shared resources.

So why are you using all of the stale stuff provided in a general purpose operating system instead of branching out to create the perfect avatar? It’s akin to getting the girl of your dreams to say “yes” for an outing, and then wearing clothes from your dad’s ‘70s wardrobe, splashing on his Old Spice aftershave, driving his 1974 Buick Electra 225, and using all of his corny lines as your rap. Why would you do that? You wouldn’t do that, yet you accept the technical equivalent of this dismal scenario with the way you are building your virtual appliance – your avatar.

Don’t settle for that weak rap. Virtualization gives you the freedom to express your application creativity. Arm your avatar with the good stuff, and forget about what the general purpose OS neanderthals say you should use. Clip-on ties, Old Spice, and Buick just won’t get it done in the virtual world of tomorrow.