Peter Christy

VMware and Spring Source, Java, System Center and Fabric Controllers

Why did VMware buy Spring Source and how does that illuminate their forward looking strategy? We've been poking at that question for a while. Some parts of the answer are simple: VMware now agrees that competing at the virtual machine level isn't such a good idea because all that is being commoditized and the value tamped down - Think of it this way: customers don't want to have to worry about important decisions at the virtual machine level and would rather put their focus and pay money for solutions to larger problems like running complex applications with good service assurance, cloud computing, SaaS and so on. If those higher levels are more important, it stands to reason that access to and leverage of the developer community is an important aspect. Spring was by far the best enterprise software framework that VMware could buy even though the market price was pretty steep. But, then, all that said and done, what can VMware really do with Spring? From a continuing set of discussions the answer seems to center around the use of Java in enterprise computing. VMware cites impressive statistics for the number of Java programmers and the use of Spring, but what do these numbers really mean ("Statistics and damned statistics..."). If Microsoft's strength in data center computing continues to grow (a fact I think) how important can Java really be? As marketing advisors we love honest statistics that lead the unwary reader to the wrong conclusion, and we don't doubt for a moment that a lot of enterprise programmers know about and make some use of Java. From that point of view, we're sure VMware's statistics are probably valid. But the most important programmer demographic statistic would seem to be the primary language that a programmer uses to get their daily job done. He may know Java but use C++ or even (dare I say the word) Microsoft's C# as his daily tool (without argument, Microsoft's Visual Studio is as good a programmer toolkit as exists). What language is most important for the enterprise developer in this sense? I've only found one company that claims to have this kind of data and their data shows that it isn't Java by a long shot. Of course you could accuse them of being biased. If Java isn't the magic sword (best we can tell), if Microsoft's System Center continues to gain strength (we heard a claim that there are more Windows Servers under System Center management than under the sum of all the competition), and if Microsoft is really actively integrating the Azure Fabric Controller into the Microsoft private cloud vision.... Geez, sounds like an interesting year for virtualization, participants and watchers alike! (If you have your own interesting statistics to share, I'm always available for a "wink wink, nod nod" this meeting never happened discussion over coffee at Philz!) — pchristy@irg-intl.com

Autonomic Computing (Redoux)

In the last issue I wrote about how VMware's acquisition of SpringSource gives them a way to interact directly with application developers, and how valuable a framework may turn out to be in Cloud and Utility computing as a way of solving important infrastructure optimization issues (like edge acceleration) without requiring the application developer to understand all the nasty bits. VMware has something even more important in mind I think: what their Analyst Day talks hinted at was that they thought that applications built on the framework could be instrumented and automatically managed as a result. If you remember, IBM tried "Autonomic" computing some time ago, and couldn't really make it work. It seems pretty clear that an executable binary is much too cryptic to make sense of at run time for broader management purposes. Things improve with virtualization because it's much easier to see what the application is doing (if not to understand it). With a framework, things improve still more because you see more of the program structure at the framework abstraction layer, and as VMware notes, you can instrument the framework to give you more useful information about what the program is doing. Are these changes enough to make something like autonomic computing really work? Remember, the goal is a smart data center than automatically dynamically adjusts to accommodate evolving load, hardware and software failure, issues of scaling, ... Our friends at Microsoft would argue I think that this isn't going to work for VMware. Microsoft thinks that by the time you get an executable program all the interesting information about the program (the design intent, how it performs and scales, how you can tell it's in trouble) has been removed or encrypted beyond all hope. Microsoft's approach (Dynamic IT) is based on the idea of capturing and preserving key design and operational data in a declarative form, and using all this in the data center to achieve the goal. Virtualization changes the game enough to make VMware's direction worth looking into, but if you asked me now, I wouldn't bet the rent money they can make it work anymore than IBM could.

VMware Acquiring SpringSource

Paul Maritz seemed a little discouraged that the analysts didn't want to ask questions about SpringSource, which is understandable since the acquisition clearly has strategic importance for VMware beyond the $420M they are paying (not chump change). The lack of questions isn't surprising if you ask how many of those analysts really know what a framework is (having managed Dev Tools for Apple, I do.) The underlying question is whether VMware can thrive building systems that manage virtual machines or whether they need to get much more involved in what happens within those VM's in order to solve the customers' important problems and profit by providing those solutions. I've never thought that VM's were the do-all, end-all, and apparently VMW has come to the same conclusion. A framework is an architecture for implementing applications and a lot of code ("subroutines" in the good old days) to support that architecture and make application programming easier by providing a higher level abstraction. Utility and Cloud computing have great benefits but come with their own challenges. For example, what kind of data storage systems work well across multiple data centers and improve application performance for remote users? Or how do you know enough about what an application is doing in order to better automate its operation (e.g., provide desired availability and scaling)? In both cases, VMware's ability to play in the game is considerably improved with access to a framework than if complex technology can be largely concealed under the framework abstraction and just come to play when needed behind the scenes without much involvement from the application programmer. Microsoft already has broadly used frameworks (Microsoft Foundation Classes and more recently the .NET Framework). It's really hard to create a framework from scratch — the value of a framework goes up quickly as more people use it so you need both the framework and the users. The Spring Framework was created as an alternative to complexity of what Sun had developed for Java application architecture, and caught on in no small part because it was open source and free. As a way of getting into the framework business (more specifically, getting in a position of influence with the developer community and being able to add mechanism behind the scenes) VMW didn't have many alternatives and SpringSource was by far the best, subject only to the high cost (spending $420M for SpringSource isn't "accretive" by any stretch of the imagination). As noted above, it isn't as if MS doesn't have frameworks or developers — they certainly do —  but it does redefine how VMW views the competition and competes. (VMware declined to comment on this story)