Vmware Springsource and Hyperic: Brave new world and a lot of questions

So Vmware is acquiring SpringSource. Like most people, my first reaction was say what? I didn’t get it; what’s VMWare got to do with SpringSource and Java ?
I read the blog posts by Steve Herrod and Rod Johnson. They were explaining their vision at a high level as expected, and it did not help much. I was still drawing a blank. I hit twitter, read some immediate reactions and subsequent blog posts, hoping they do the hard work and spell it out for me. No such luck. Comments were so diagonally opposed to one another that I’ve concluded it wasn’t just me who was confused. @daveofdoom thought Hyperic was a key tech, Reuven Cohen concluded that, Hyperic was unneeded by VMWare and would be shut down. Confused yet?

A sneaking suspicion has come over me: We don’t understand what these guys are really up to just yet, and they are up to something groundbreaking, that may shape the future.

No help from usually insightful sources, (amazing how easily I got used to readily available quality analysis for free!) I had to do some thinking and speculation myself. I reread the announcements and started thinking.

First, why am I interested? We use many of the technologies provided by these companies in some form. iFountain is a java shop, and use VMWare for development and testing. Our product RapidInsight is built on Grails and heavily uses Groovy, and has integration with Hyperic (one of the best server/application management solutions in the market, open source or otherwise.)

What does this acquisition mean to us?
1. VMWare Springsource Java stack combination.
As mentioned in Steve Herrod’s post, it no longer makes sense for the VMs to be ignorant of the applications running on them. VMs and the applications need to be introduced to each other. If they become good friends, and start talking and sharing, all kinds of cool things can happen.
In my experience, actual hardware and operating system has lost its importance a while ago. If you develop pure java applications, JVM becomes your environment. Why do we need another layer of abstraction, especially if it is virtual? To run a java application like RapidInsight in the cloud (EC2, etc.) or on VMWare hosted image, one has to create an OS image, configure it, make it secure, maintain/administer it, etc. just to host the JVM so that java app can run.
What if instead, VMWare could run JVMs natively just like it’s running linux or windows?

JVM running natively without an OS would presumably have a lot smaller footprint, and save resources. However, more substantial savings would probably come from eliminating administrative overhead of managing the OS.
From an ISV standpoint, this combination may enable ISVs to deploy applications in VMWare JVM ready format, to be installed and running within minutes.

2. Instrumentation of the applications and VMware
Hyperic is different than other solutions in the market it’s competing. It has an agent that is installed on the host and can gather in depth information that is essential for the “conversation” between the applications and VMware.
Using Hyperic, applications can be instrumented, giving in-depth information on how the application is performing, etc. Imagine VMWare assigning another CPU and more memory to the JVM on the fly automatically based on various performance parameters! (afaik neither is currently possible without a restart of the JVM). Now that would be something!

3. Development tools – cloud integration
We use various VMWare images for development. Having an IDE that is integrated with the cloud (VMWare) resources and enable running apps directly on the cloud by push of a button from IDE sounds good to me. If VMWare/Springsource continues to invest in having great support for Groovy and Grails in Eclipse, and integrate it with the cloud, it will be a great combination.

In short, I can see VMWare becoming THE platform for us to develop our products. All of a sudden, this is not such a crazy acquisition. Hats off to everyone involved, there is some great potential here!

From traditional IT management perspective, things are a bit blurry. Springsource acquisition of Hyperic hinted that Hyperic may become more of a specialized management vendor, focusing on java application management. With the acquisition of Springsource by VMWare, this has become a stronger possibility.

With this acquisition, Hyperic (product line) is moving into dominating the future of IT management with a vertically integrated solution. Does VMWare intend to compete in the traditional IT management market with the likes of Zenoss, Groundworks, Tivoli, HP, BMC, etc. as well, or will they gradually abandon this market? What is the future of Hyperic product line, if any, apart from being a key enabling technology for VMWare’s cloud platform?

Reblog this post [with Zemanta]

6 thoughts on “Vmware Springsource and Hyperic: Brave new world and a lot of questions

  1. williamlouth

    “Hyperic is different than other solutions in the market it’s competing.”

    What exactly are you referring too? Hyperic is complete void of application interactions and largely relies on process level metrics (no context, no interaction, no activity chain, no correlation) published as MBeans and instrumented by developers of applications and technologies within the stack.

    Assigning more cpu does not at all solve a scalability or performance problem in the cloud unless your are aware of the nature & profile of the activities (io bound, cpu bound, mixed) queued and how they interact (bottlenecks) with each other in competing for resources.

  2. berkay

    William,

    Thanks for the comment.Hyperic is typically compared to more generic monitoring tools like the ones I've mentioned above which typically don't have an agent on the box and rely on SNMP or WMI.
    I understand your argument that deeper and more efficient insight into applications is needed to resolve scalability and performance problems (like provided by Jinspire)

    By assigning CPU and memory, I was referring to elasticity rather than scalability/performance problem originating from the application. In a VMWare box with 32 CPUs and 128GB memory hosting multiple JVMs, VMWare can potentially change allocation of CPUs and memory to applications based on the load for each app, making better use of the available resources.

  3. williamlouth

    Actually most of the other vendors such as Tivoli, HP and BMC do provide agents for the Java runtime though in most accounts they are disabled because of the large overhead they generally incur and the poor value delivered by what is collected. Tivoli has probably one of the worst track records in this regard followed by HP. Most customers buying into such products are also buying into the complete ITIL product management suite including help desks, cmdbs, slm, bsm,… which is completely out of the range & possibilities of Hyperic and its team.

    You are probably right that Hyperic will target specifically Java now considering that SpringSource had indicated that they were going to do a complete rewrite which follows on from two other complete rewrites by JBoss and Hyperic itself. If a complete rewrite is underway then management would probably look to minimize risk and reduce the scope. That said I would not be surprised if Hyperic is not put to rest as VMware has already invested in tooling around its management console(s).

    I still think we are a very long way away from are sort of automated dynamic provisioning until we can accurate collect and model the underlying software and system execution models.

  4. Bill

    Spring is running on the JVM, just like JBoss etc. VMWare do not have to buy a Java framework to do JVM stuff.

    VMWare could do a “bare metal” jvm os, and you could run Java app on top of that. You dont need Spring to do that.

  5. berkay

    Agreed.
    VMWare may be able to do more than bare metal jvm OS with Springsource, They can go further app the stack and create something like Google App Engine for the enterprise, without the limitations of GAE.

Leave a Reply