VMWare, SpringSource to revolutionize Java development
VMWare's acquisition of SpringSource this week is a significant development in the history of the Java development platform.
I have been working closely with VMWare for some time now, and I know a little bit about how the company sees its role in the cloud. The acquisition of the commercial open-source middleware/framework company makes perfect sense to me.
SpringSource gives VMWare a development "platform," of sorts, to deliver in VMWare-based cloud services and a unique declarative environment in which to define both application construction and deployment architectures. The vision painted by SpringSource CEO Rod Johnson speaks to an environment in which developers can declare not only how objects should connect with one another, but how they should be packaged into virtual machines and deployed into the virtualized infrastructure:
Working together with VMware we plan on creating a single, integrated, build-run-manage solution for the data center, private clouds, and public clouds. A solution that exploits knowledge of the application structure, and collaboration with middleware and management components, to ensure optimal efficiency and resiliency of the supporting virtual environment at deployment time and during runtime. A solution that will deliver a Platform as a Service (Paas) built around technologies that you already know, which can slash cost and complexity. A solution built around open, portable middleware technologies that can run on traditional Java EE application servers in a conventional data center and on Amazon EC2 and other elastic compute environments as well as on the VMware platform.
Much of the early analysis of this acquisition has focused on how it plays as a counter to Microsoft Azure, which--when combined with the Hyper-V virtualization platform--threatens VMWare's dominance in the enterprise. Forrester Research's James Staten thinks it's much more than that, however:
VMware has a bigger agenda SpringSource helps to fulfill making vCloud bigger than simply an Infrastructure as a Service (IaaS) alternative and keeping Microsoft at bay. Enterprises are already demanding that cloud environments and internal cloud solutions support their hypervisor standard VMware. So it wasn't going to be a stretch to get vCloud adopted, assuming it delivered as promised. But the battle isn't IaaS, it's becoming the equivalent of the operating system for the next generation data center and you can't achieve that aim without applications; and you can't become application-relevant without being relevant to developers.
Redmonk's Stephen O'Grady thinks it's not just about the development and integration, but also about tooling:
When (colleague Michael) Cote and I met with SpringSource CEO Rod Johnson at OSCON a few weeks ago, one of the primary topics of discussion was the development experience. This could wind up one of the unheralded benefits of the acquisition: Rod gets the tooling story. He understands that Microsoft, again, is setting the bar for the development experience by allowing its developers to localize the cloud environment via Visual Studio. With VMware's virtualization capabilities, the tooling story for SpringSource could get very interesting vis a vis cloud development and deployment.
This goes to the vision that has me most excited about the future of cloud computing right now. I think that there are technologies evolving for both public and private clouds that actually give developers and solutions architects just as much control over every element of how their applications are built, deployed, and operated as they have had in the past.
These technologies are a combination of declarative descriptive configuration policies and automated software and systems that can interpret those policies and respond as required. Contrary to Harvard Professor Jonathan Zittrain's well-read New York Times OpEd piece, developers would keep control over their application environments.
SaaS offerings could allow for customization at levels of granularity unthinkable before Spring demonstrated dynamic instantiation. Custom applications deployed to IaaS offerings could declare that they require a isolated networks for backplane communication, connectivity to two different storage systems by name (perhaps even one in the cloud and one through FCoE), or provide monitoring through specific protocols.
By the way, I don't think VMWare is the only company that can achieve this vision. As noted in the earlier quotes, Microsoft is in a great position to allow a similar story for its developers, assuming it partners with the right systems companies to push dynamic configuration beyond Hyper-V into the physical infrastructure layers. .Net and the Microsoft tool set are already quite capable of delivering significant coordination between application development and deployment. Citrix and Red Hat, by contrast, do not yet seem to have such a sophisticated vision.
Oh, and VMWare got cloud monitoring powerhouse Hyperic in the deal as well. More on that in a later post.
I'd love to hear your opinion of the VMWare's acquisition of SpringSource. Is it as important as the cloud pundits and I say it is, or is there little excitement to be found here?
Follow James Urquhart on Twitter.
James Urquhart is a seasoned field technologist with almost 20 years of experience in distributed systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is currently market manager for the Data Center 3.0 strategy at Cisco Systems, though the opinions expressed here are strictly his own. He is a member of the CNET Blog Network and is not an employee of CNET. 
James you sound like some a dot-com groupie that never knew a thing about technology (but followed the crowd and money) which we both know is not the case. So please explain to me how you could make such a statement unless you are just repeating what Javier would like everyone to believe whilst anyone with some degree of intelligence, understanding of software and IT management, access to the source code, would immediately put such claims away in their rightful place - the dust bin.
Hyperic cannot even scale in the enterprise context never mind in the cloud. Monitoring is dead in the cloud context. Metering is the future and its multi dimensional and fine grain.
How many rewrites does it take for someone to realize that beneath the surface all is not right. Why not ask some JBoss employees of their opinion? If they had the chance they would restart form scratch after wasting years with this codebase.
Spring itself has very little in the way of cloud computing but I do expect them to develop and acquire the necessary building blocks, such as a data grid as well as a compute grid, to deliver on what this sales is meant to be all about.
If it isn't clear yet, I believe most enterprises will at least initially (and probably for the forseeable future) will want to own their own management and monitoring infrastructure--not for infrastructure (servers, storage, etc.), but for applications (with some ties to the virtualization products the applications run on).
So each facility would only have to scale to the needs of that single enterprise. Not that much of a stretch, frankly, with the possible exception of monitoring large scale data processing apps (e.g. Hadoop-based apps), but those could be monitored in the aggregate, rather than at a server-level granularity (or so I hear--I have no experience with Hadoop programming or deployment).
That said, everything I hear about Hyperic makes it clear it designed for "application down" monitoring. If execution is less than perfect, that's disappointing, but VMware had deep pockets, and those issues can be quickly addressed.
For Spring, there are some reasonably high scale applications written on it--CMS vendor Alfresco, for instance, has some very large deployments, including consumer web-facing applications. There are others as well. Again, it only has to scale to meet the needs of each application, and doesn't have to serve as a multi-tenant architecture in and of itself.
So, that being said, there is no doubt that "powerhouse" sounds a little "fan-boy" in this context. Hyperic is a very interesting player in the space, but still not a giant player, and may or may not have execution issues that I am not aware of.
- by williamlouth August 14, 2009 2:51 AM PDT
- Hi James,
- Like this Reply to this comment
-
(8 Comments)Hyperic is NOT application focused at all which I assumes means looking inside a process to see what it is actually doing, how it comes resources, and why. A few minutes on the hyperic forums and you would see this for yourself. The questions are all focused on monitor the health status of various processes. Even customers that have Hyperic complain that it rarely has the application metrics they need. This is why JBoss ON 1 (hyperic clone) & 2 (hyperic rewrite) has not gained the traction RedHat would have hoped and why SpringSource AMS (another Hyperic clone) was effectively dead on-arrival. Hyperic before SS acquired it had nothing to offer in this area other than a few measly JMX attributes (which is one of the reasons is cannot scale the other main one being its architecture).
Maybe you are talking about Hyperic 2.0 (the SS rewrite).
By the way Alfresco is certainly not a poster child of a good Spring application. The last time I looked it took 500 spring beans and 20+ xml configuration files just to open up a simple JCR session to a repository.
Look as soon as a cluster wide aggregated metric changes people want to know why. You are just teasing (and frustrating) your users with a dashboard that cannot do more than this. Now that cost is tied to performance and capacity management we need a whole new approach.