This post has already been read 19521 times!
During his technical keynote at VMworld, Stephen Herrod added a fourth leg to the now familiar previous three legs of the VMware strategy. The previous three were View (Desktop), vSphere (the data center), and vCloud (the internal and external clouds). The new addition was the elevation of vApps to a fourth leg in the stool which describes the VMware strategy. This fourth leg of the stool is all about VMware as an application platform, and VMware adding value directly to how applications run. This new fourth leg ultimately results in a new strategy from VMware allowing applications platforms (and therefore applications) to be run directly in a VMware Guest without the need for an underlying Windows or Linux operating system.
The first step in VMware’s application platform strategy is has two parts to it. Part one is to encapsulate each combination of OS, Middleware, Application FrameWork and Application into a Guest. This is what VMware does today. The second part is to encapsulate multiple VM’s that collectively comprise an application system, along with their run time rules (network and security configuration) into a vApp. This is a nice incremental step that adds a lot of value, but does not turn the world upside down in any way, or replace the roles of any of the key products or vendor in the “stack”.
The last step is truly radical and if successful will usher in enormous changes in the computer software industry. It is already the case that most applications that are built today (and have been built in the last few years) are not actually built to the API’s that are directly part of an operating system. It is the case that most applications are built to run-time frameworks that run on top of operating systems like Windows and Unix, instead of the API’s provided by the OS itself. Think of the difference between the Win32, WFC, and COM+ API’s that are part of Windows (rarely used by applications these days) vs. the .Net interfaces that are part of the .Net applications framework (now the standard Windows applications interfaces). The same is true on the Java front. You do not run a Java application directly on a Windows OS or a Unix/Linux OS. You run it on a runtime framework like Weblogic, WebSphere, TomCat or SpringSource.
Now that VMware has acquired SpringSource it owns a popular, simple to use, portable, open Java run time framework. The conversation at VMware has already started about how to make services in vSphere directly available to the framework so that applications built to the framework can automatically take advantage of services provided by the underlying virtualization platform. One simple example would be that the web tier of an application knows what access it needs to the business logic tier (ports) and this information can simply be communicated to the virtualization layer at run time. Another one would be that a mechanism could be provided so that a developer of the application can tag the start and end of a transaction in their code, which would then let a monitoring solution like AppSpeed automatically time the response time for complex multi-step transactions. All of this falls into the category of adding value, and is not the radical game changing part.
The radical game changing part is what is missing from the picture below. Note (that as I have previously predicted) the OS is not present in the picture. That’s right, VMware is going to directly glue the frameworks that it either has some control over (SpringSource) or the ones that it can easily influence (all of the open source ones, by simply contributing libraries to the distributions) to the VMware Guest infrastructure. This means that if you use one of these frameworks to run your applications, you will 1) be able to get direct access to VMware functionality as you build the application, and 2) not have to install or pay license or support fees to an OS vendor. The tricky part in this strategy will be convincing Microsoft to go along.
Microsoft will therefore soon face a Hobson’s choice (a choice of two bad alternatives). Once choice will be to ignore all of this and risk having developers flock to a platform that lets them spend a whole lot less time worrying about deployment and run time management issues (two things developers hate spending time doing). If VMware is successful this means that over time Microsoft’s share of developer mindset will erode (some will say even faster than it has been). The other choice is to play along and glue .Net directly to the VMware infrastructure in the manner depicted below. To protect its revenue stream Microsoft will have to try to charge customers the same license fee for the .Net runtime that Microsoft charges for the full Windows OS, which means admitting that if .Net is worth as much as Windows, then Windows must be worthless.
Red Hat faces a similar issue, and in fact an even greater threat than Microsoft for the simple fact that most of the applications that are built to Linux are in fact built in either Java or one of the other non-Microsoft frameworks listed in the picture below. If you can run the Linux (Java, PHP, Ruby on Rails, Python, etc.) application of your choice on VMware without having to pay support fees or license fees to Red Hat then why should you not take that offer.
The same logic applies to vendor of expensive and complicated Java middleware layers like BEA/SUN/Oracle Weblogic, and IBM Websphere. VMware is eliminating the economic rationale for the existence of these products.
As I have written before, this is the first existential threat that the Windows franchise has ever faced. It has never faced an alternative that owned the hardware layer, provides OS services, provides an application API layer and that adds enough value so that customers are willing to rapidly embrace it. This is not something that Microsoft is going to take lying down. The house of Microsoft is largely build upon the foundation of Windows, so if Windows decreases in relevance, so in turn does Microsoft.
What can Microsoft do? The only course of action that I see is for Microsoft to ally itself with everyone else who is threatened by VMware (Red Hat, Citrix, Oracle, the Websphere group at IBM) and create an alternative standard to VMware. The logical choice here is XenSource which is already embraced by everyone except Red Hat, and which Microsoft could embrace relatively easily (since Hyper-V is a derivative of XenSource). This also opens the door for Microsoft to aggressively partner with Amazon, since EC2 is also based upon XenSource. In summary, VMware is now a large enough threat to all of these players that divided they are certain to fall, and that banding together is their only chance.