Let me start with a few disclaimers. By virtue of working in the IBM WebSphere Application Server team, I compete with SpringSource. I know, and like, several of the key people at SpringSource. I'm happy that their hard work paid of with such a large exit. While I compete with SpringSource, I'm excited that this acquisition will raise the bar for vendors that I care about, and ultimately, customers will benefit the most.
That said, although there has been a lot of analysis of VMware's acquisition of SpringSource, by in large it has accepted the vision of clouds and platform-as-a-service (PaaS) laid out in VMware's press release as a likely outcome. Let me try a different approach by discussing what VMware really bought.
VMware bought SpringSource because "Spring is everywhere"
Yes, but sadly for VMware, no. The Spring Framework is widely used in the enterprise Java market. From my own experience, many WebSphere customers use the Spring Framework on top of WebSphere. However, many WebSphere customers use the competing EJB open standard in place of the proprietary, but open source, Spring Framework. The most recent Eclipse user survey results found that of the 436 respondents building server-side applications, 47.5 percent were using the Spring Framework and 38.3 percent were using EJBs. Customers clearly exhibit a need for choice significantly higher than the proclamations of Spring's enterprise Java domination would suggest.
With such a high usage penetration, one could expect a significant revenue base for SpringSource. Yet, SpringSource is estimated to have driven $20 million in revenue, or maybe bookings, mainly from professional services. This is a very respectable base for a company with 150 employees. IDC, however, estimated the 2008 Application Server market at nearly $3.8 billion. While the Spring Framework is widely used, SpringSource has not been able to extract significant market share as a result.
VMware may believe that adding its brand and sales reach to the SpringSource portfolio will drive higher revenue from the Spring Framework and related Spring products. RedMonk's Stephen O'Grady subscribes to this view, using the MySQL acquisition by Sun as a proof point. I disagree, because a framework is different than a database and the other Spring products have nowhere close to the penetration of the Spring Framework, as I discuss below. Additionally, if a customer has been using the Spring Framework for the past five years without a support contract or subscription, why acquire support or a subscription now? The only reason for doing so will be if VMware and SpringSource disadvantage the open source Spring Framework in favor of the enterprise, commercially licensed Spring Enterprise. The community uproar the last time SpringSource tried this approach leads me to believe that VMware and SpringSource won't go down this path again.
VMware bought SpringSource because SpringSource now has a "Build-Run-Manage" story
Yes, but sadly for VMware, no. Trying to build a significant business selling support subscriptions to the large number of Spring Framework users proved to be a tough nut to crack. The key insight for SpringSource was that customers paid for runtimes and integrated administration and management of runtimes, not for frameworks. SpringSource responded by acquiring Covalent and Hyperic in order to deliver two runtimes, SpringSource tc Server and SpringSource dm Server with administration and management capabilities via Hyperic. SpringSource has introduced a "build-run-manage" marketing campaign, which always makes me chuckle as I recall IBM using Build-Run-Manage back in the early 2000s. I understand that SpringSource is attempting to educate the market that it is no longer only a framework provider, and now have not one but two runtimes that customers can purchase.
It's arguable that one or both of these products will become the basis for VMware's beachhead into the middleware market. So what are the prospects for tc Server and dm Server?
Since tc Server is aimed at Tomcat usage, it's important to ask what customers running large Tomcat environments used before tc Server came to market? Well, some used Tomcat without support. Others used JBoss, Geronimo, GlassFish, and WAS Community Edition, which deliver Tomcat inside. Still others purchased Tomcat support from Covalent, OpenLogic, etc. For the most part, customers who have not purchased Tomcat support or management for five-plus years are not going to buy a product now. If customers were missing some of the management capabilities that tc Server provides, by now they would have built this capability in house. I know of several large Tomcat users that fall into this category. The customer now has to consider the sunk costs of their custom code versus the cost of acquiring a new product. Customers that have purchased Tomcat support are targets for tc Server, but they are also being targeted by JBoss, Geronimo, GlassFish, and WAS Community Edition. It's not yet clear that tc Server provides differentiated value that will allow it to win disproportionately against the other products. The important insight is that very few Tomcat users are using just Tomcat. They use other parts of a Java Enterprise Edition (JEE) stack, such as JMS messaging or Web Services. So the choice between tc Server with just Tomcat runtime features or a JEE product which includes Tomcat and other JEE APIs is not as cut and dry as SpringSource's marketing would suggest.
In the nearly 10 months since dm Server became generally available, I've frankly heard of virtually no customer usage. But don't take my word for it. Ask your neighborhood Java developer if they've heard of dm Server or if they've used dm Server. The key issue with dm Server is that it's proprietary. Developers and their managers were comfortable using the Spring Framework because while the framework was proprietary, they could easily move their applications across multiple standards-based JEE application servers. Protection from vendor lock-in was delivered by the runtime application server. Customers continue to expect this. If you build a dm Server application, there is exactly one runtime it will run on. Hence, dm Server fails the vendor lock-in test, and its adoption is a testament to this failure. This is, however, a fixable problem for VMware. dm Server could be evolved to meet the forthcoming JEE 6 Web Profile specification, which Geronimo, GlassFish, JBoss, WebLogic, and WebSphere are all expected to support.
VMware is going to find that broad usage of a framework or having a Build-Run-Manage story does not easily translate into customers migrating off their existing Java standards-compliant application server runtime to a proprietary runtime.
VMware bought SpringSource because of the cloud and PaaS angle
Yes, but we'll see. Cloud and PaaS are the two reasons that VMware and SpringSource have claimed as motivations for the acquisition. I couldn't say it better than RedMonk's Stephen O'Grady:
In time, yes, quite possibly. And there's little question that SpringSource offers VMware an intriguing opportunity to be what 10gen, Project Caroline, et al have to date failed to be: the EngineYard or Heroku for Java, permitting seamless deployment of Java applications to on or off premise cloud infrastructure. But this is, to me, a longer term revenue opportunity, as VMware's cloud pieces are still coming together and its hardware and datacenter capabilities are neglible relative to competition such as Amazon, IBM or Microsoft.
Additionally, whether or not VMware and/or SpringSource will acknowledge it, customers are already deploying Java applications to a dynamically provisioned and policy-based managed cloud. This isn't a two or three years from now capability. As we speak customers are using IBM WebSphere CloudBurst Appliance with WebSphere Application Server and WebSphere Virtual Enterprise. The point is not to discuss IBM products, but rather to highlight that the VMware and SpringSource future vision is already a reality, and it's a reality that is driving significant IBM WebSphere revenue around an on-premise cloud environment.
Lastly, since an application runtime environment is critical to a PaaS or cloud deployment, I'd go back to the fact that SpringSource's runtime environments, tc Server and dm Server, are starting from a standstill in an uphill battle for revenue share. While VMware works to establish tc Server and dm Server penetration, VMware will have to be careful not to alienate their application server partners -- the ones whose products are driving virtually all of the application server spending today. This level of coopetition is doable but not easy. But hey, VMware has 420 million reasons for doing difficult but necessary things.
VMware bought SpringSource because of Microsoft
Yes. Larry Dignan's excellent analysis of the acquisition highlighted some very interesting data from a financial analyst, Pritchard:
In our view the acquisition highlights the vulnerability VMware has in its exposure to Microsoft. We estimate north of 80 percent (may be as high as 90 percent, with the rest being Linux) of VMware virtual machines are running Windows server and an application developed in Microsoft's .NET environment. This is a key strategic vulnerability as Microsoft has a history of absorbing functionality such as VMW that is essentially a layer in the Microsoft stack. Ultimately SpringSource technology may enable VMW to add enterprise Java workloads to diversify away from Windows.
Microsoft is clearly going after VMware with Hyper-V inside of Windows Server 2008 R2:
We've got a great solution. It's a sixth the cost on average of what we see in the marketplace. Evangelizing the tax that VMware is getting from the product is something we look forward to competing with in this environment. Again, it's about getting specific. It is about getting aggressive, and that's where we're headed.
In an effort to guard against Microsoft marginalizing VMware's core virtualization business, the SpringSource acquisition puts VMware at odds with Java runtime vendors who collectively represent the approximately 50 percent of the enterprise market not associated with .Net. I don't see how SpringSource helps VMware versus Microsoft in the estimated 80 percent of VMware environments where the application has been developed on .Net, as Pritchard suggests. If the application is .Net based, and the hypervisor is running on top of a Windows host, then this is Microsoft's customer to lose or win back from VMware. VMware is clearly looking past its current deployments, where Windows and .Net dominate, to a new Java-based cloud and PaaS environment. But we already covered that aspect and the competitive hurdles in the cloud/PaaS portion of this post.
It's not just Microsoft that is marginalizing the value of a hypervisor. As mentioned above, IBM WebSphere CloudBurst Appliance and WebSphere Virtual Enterprise treat the hypervisor as an infrastructure component of equivalent value to the host operating systems. Said differently, the hypervisor, like the operating system, has little impact on the application performance, reliability, availability, or TCO. Those application characteristics are enabled through the runtime application server and the dynamic provisioning and management framework around the application server. This is how IBM's cloud solution is designed. I'll wager that Oracle's and Red Hat's offerings will push value up the stack, beyond the hypervisor layer itself.
VMware bought SpringSource because of the great people at SpringSource
Yes. There is solid talent at SpringSource. VMware has set aside $60 million in retention funding for the approximately 150 SpringSource employees over the next four years. This $60 million was discussed on the VMware investor call and is in addition to the acquisition price. This will clearly help VMware retain SpringSource talent. SpringSource employees will also want to stick around to bring their vision of world domination to fruition ;-)
There is much opportunity and risk for VMware with this acquisition. If VMware can execute well, it'll save the company from peril at the hands of Microsoft and Hyper-V and application server vendors who are minimizing the value of a hypervisor to the level of the underlying operating system itself.
This acquisition raises the competitive bar for vendors with application server and/or hypervisor offerings. That's something customers should be happy about. Fun times ahead!
Follow me on Twitter: SavioRodrigues.
p.s.: I should state: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions."