By now most of you have probably heard BEA's claim that the new Virtual Edition of its WebLogic Java application server (aka WLS VE) can run directly on VMware's ESX hypervisor without the need for an intervening operating system. In other words, from now on you will be able to spend all your hard-earned software dollars on BEA and VMware alone, while cutting Red Hat and Microsoft out of the picture completely. (I suspect you still might want to save a few bucks for Oracle, but that's another story.) As BEA puts it, by eliminating the need to buy and install a server operating system, Virtual Edition:

"... allows more applications per server, significantly reducing hardware and operations costs and greatly simplifying deployment."

Can this claim possibly be true? The short answer is: no, of course not. BEA has not "gotten rid" of the server OS. It has merely replaced the regular, branded, off-the-shelf "fat" OS with a slimmed down "OS shim" of its own confection. Before you can run WLS VE on a VMware ESX virtual machine, you have to install something called LiquidVM. This is just a pre-configured software appliance consisting of BEA's JRockit Java Virtual Machine (JVM) and its OS shim. The idea of software appliances is not new and is in fact pretty popular these days (see my earlier post on rPath here), but I have to admit BEA has been unusually creative here.

BEA's OS shim has been stripped down to the barest essentials of what a normal operating system provides. It performs networking, thread-scheduling, memory management and file storage only. No GUI, no device drivers, no user space utilities, no management console. The shim can run only a single kernel process that is reserved for the JVM, nothing else. It doesn't expose any non-Java interfaces to the outside world. This means Java applications running on the LiquidVM appliance won't be able to do things like invoke Perl scripts or use ActiveX components to access Microsoft Office, or indeed run any non-native code at all. The appliance is 32 bits only for now, so you can't run Java apps that require more than 3.5 GBytes of heap memory. Also, LiquidVM can't run from the local disk on the ESX server machine, it requires a Network File System (NFS) file server to read and write files.

You might be thinking that BEA's "skinny OS" is based on Linux. That would be a reasonable guess, since lots of software vendors use embedded Linux. Heck, even the Console Operating System in VMware's own ESX is a version of Red Hat 7.2. But BEA has taken a slightly different route. The company says the shim is "not based on Linux", but instead uses a "POSIX based *nix emulation layer" that has been "built from the ground up" (by whom they don't say). I'm guessing this means they've taken some flavor of the BSD kernel and modified it to suit their needs. Of course, unlike GPL'd Linux, open source BSD code has the advantage that anyone can appropriate it, change it, and then "privatize" the results into a closed-source proprietary product. Apple and Microsoft know a thing or two about privatized BSD code.

Is there a big payoff for sacrificing the standard server OS? You might have gotten the impression from some of the media coverage that BEA is touting big performance gains from WLS VE and LiquidVM compared to the standard virtualization stack with a "fat OS." And as a matter of fact I did hear some loose talk from BEA execs this week at the company's BEAWorld show in San Francisco about how WLS VE delivers "40% better performance" than Red Hat running on VMware ESX. But in the company's published statements it carefully stops short of any such performance enhancement claims. It's not clear to me why WLS VE should run any faster than a full stack virtual machine with Red Hat or Windows Server, because in all cases there is still an operating system performing the same necessary set of basic OS tasks. The extra code in the "fat" versions might take up space, but since it's not actually running it shouldn't slow down execution.

It turns out the main technical advantage BEA touts is precisely that Virtual Edition has a much smaller memory and disk footprint than a normal virtual machine. This means you can stack more virtualized Java applications on the same piece of server hardware, in optimum cases twice as many according to BEA. It also means that when you want to hibernate a virtual machine or wake it up, the size of the snapshot that has to be written to or read from disk is much smaller, and therefore the process completes faster.

BEA also somewhat optimistically argues that VE has "less potential for security incursions" because it exposes a smaller surface for hackers to attack. However, it also imposes the use of NFS but doesn't yet support NFS encryption, so someone listening in on your network could theoretically see the packets between the file server and the virtual machine go by in the clear. Let's call the pros and cons on the security front a wash for the time being.

The current version of WLS VE lacks a number of other key features that are promised for future releases. Supposedly there will be a version for the open source Xen hypervisor "by the end of the year", as well as a version sometime next year for Microsoft's Windows Server virtualization offering (the Xen-like hypervisor formerly known as Viridian, designed to accompany Windows Server 2008). There will also be a 64 bit version in due course.

But the biggest piece of missing functionality is something called the Liquid Operations Center, which BEA insists on referring to by the creepy acronym "LOC". No, it's not the Loch Ness monster. LOC is a very ambitious product that I suspect is the real reason for the launch of WLS VE. BEA describes it as a management console and framework for automated, policy-driven provisioning and migration of virtualized Java applications in the data center. This is something that could be quite compelling for the big Fortune 500 Java shops who are BEA's bread and butter.

Basically what LOC does is take a software appliance consisting of LiquidVM and a running Java application and treat it as a virtual container that can be shipped around the data center like a box of files. Suppose you need to move a certain Java application that is experiencing a spike in demand from a server with, say, four processor cores (two sockets filled with dual core chips) to a server with sixteen cores (four sockets filled with quad-cores). LOC can perform this task from its console and even automate the process based on policies you declare. If this sounds to you a lot like software startup Cassatt's data center automation platform Collage, you're not mistaken. It's an interesting coincidence that Cassatt's CEO is none other than Bill Coleman, who is both the "B" of BEA and its former CEO (current CEO Alfred Chuang is the "A"). However, as far as I know there is no connection between Collage and LOC.

WLS Virtual Edition has another new feature which, though it isn't technical in nature, could have a big impact, and that is per instance pricing. If I am not mistaken, the list price for a traditional non-virtualized WebLogic application server license is around $10,000 per CPU. A few years ago BEA tried to add a 25% premium to its per CPU price for dual socket processors, but quickly backed down after a customer outcry. But even without a multi-core premium, ten grand per CPU socket is a lot of money, especially when you've got a few racks full of servers with multiple sockets per server. No doubt large customers get a hefty discount off this. Still, it's easy to see why enterprise Java from big brand vendors like BEA or IBM is a pretty rarefied market these days compared to the far more common .Net, PHP or JBoss implementations. With per instance pricing BEA is not exactly starting a price war with Microsoft and JBoss, but it is changing the rules of the game in a potentially far-reaching way.

An instance of WLS Virtual Edition will be licensed at $13,000. But an instance license will behave in a fundamentally new way. A traditional BEA CPU license varies in price with the number of physical CPU sockets it is assigned to and it is restricted to a specific IP address.  But with a Virtual Edition instance running on a hypervisor-based virtual machine, it doesn't matter which hardware server you are running or how many physical CPUs your box has. For example, you could move a virtualized Java application from machine A with four cores to machine B with 16 cores with no change in price. Both will count as the same single license instance. Of course, BEA hopes customers will stack up lots of virtual instances on each hardware machine, thus allowing it to make its money back and then some. Instance pricing probably won't turn out to be cheaper, but there's no denying it should make license administration a lot simpler.

Are Microsoft, Red Hat and Novell going to lose lots of OS sales because of WLS Virtual Edition? That's possible, but not certain. Relatively few BEA customers are running production WebLogic servers on VMware today, and those that are probably have better things to do than fool around with software stacks that are already up and running. So probably no one is going to rip out existing copies of Windows Server or RHEL or SLES to run WLS VE on bare VMware. Going forward of course things may change. The automated provisioning features of LOC are likely to prove attractive to customers who are running data centers full of WebLogic. BEA also hints that its Java-based Enterprise Services Bus (ESB) will eventually run on LiquidVM. That will increase the number of potentially OS-less servers in organizations that decide to build large-scale Service Oriented Architectures with BEA software.

Every new installation of Virtual Edition will mean the loss of at least a fractional license for the OS vendors. Remember, Microsoft and Red Hat allow multiple virtual OS copies to run for the same fixed price on the premium versions of their server platforms, so not every WLS VE instance will mean the loss of a full "fat" OS license.

Longer term, if WLS VE gets real traction in the market, I would expect Microsoft and perhaps Red Hat to respond in kind. Microsoft has already moved a step in the appliance direction with the Server Core feature announced for Windows Server 2008. Server Core is a stripped-down GUI-less version of the full OS that is said to require only one sixth as much disk space. If BEA demonstrates that there is a market for this kind of thing, I'm pretty sure Redmond could take Server Core and package it up with its equivalent of the JVM, the Common Language Runtime component of .Net (aka the CLR).
For Red Hat things might be a bit more complicated. Red Hat can obviously do its own small footprint version of core RHEL, but it doesn't control its own JVM. Instead it assumes that JBoss will be installed with a third party JVM such as the one provided with Sun's JDK. However, now that Sun's HotSpot virtual machine has been released under the GPL, perhaps Red Hat could tweak it to run as part of a bundled appliance stack under JBoss.

All in all, I think Microsoft is less vulnerable and has a bigger opportunity here than Red Hat. A commonly misunderstood fact about the current state of VMware ESX usage is that a substantial majority of the virtual machines out there are running some version or other of a Microsoft operating system, not Linux. This may be due to the fact that Microsoft has a much bigger legacy server OS installed base than the major enterprise Linux distributions. There are just a lot more Windows-based applications sitting around on under-utilized server hardware waiting to be virtualized compared to Linux, which is a more recent phenomenon in corporate data centers. But that means Microsoft has a bigger opportunity to take back market share from VMware when its own hypervisor comes out next year. If customers are also demanding to "containerize" their .Net CLR installations by running them on a bare hypervisor in the same way as BEA's WLS VE, then my bet is Microsoft won't want to disappoint them.