Posts Tagged ‘Groovy’

SpringSource + Hyperic = Better Together

May 4th, 2009 Comments off

Hi all,

This is the post I accidentally posted prematurely a couple weeks ago. Since its now relevant – I decided to repost it. Congrats to the team once again!

SpringSource + HypericRumors have been circulating for a while now, and today it is official. I’d like to congratulate all my friends at Hyperic on this new marriage. I’d also like to offer some outsider-former-insider perspective on why I think this is a great thing for both companies.

First, a short reminder on its history. Hyperic was born from a previous company called Covalent. Covalent (v1 as we like to refer to it), simply put was formed to commoditize the Apache project. It built tools and contributed modules to Apache that helped users deploy it faster, improve reliability, and ease management of the performance of the applications running on it. This last bit was what would become Hyperic. Hyperic grew the project as a separate entity to leverage its modular architecture to cover even more technologies. More than 75 in fact, including JBoss, BEA WebLogic, MySQL, Red Hat, Microsoft technologies, VMware, Citrix XenServer and more. A few years ago, while Interface 21–the previous moniker for SpringSource–was expanding their capabilities to make Java Application development faster, more reliable and more scalable, they looked at Hyperic to embed as their management project. Working at Hyperic at the time, the Spring engineers quickly earned the respect and admiration of the Hyperic engineers. They did nothing short of an awesome job extending and improving the embedded Hyperic application for Spring. Last year, SpringSource aquired Covalent Technologies (also sometimes called v2 internally) to add its products to their portfolio – adding commercial support for Apache and Tomcat in the process. An aquisition that has been met with resounding success from Spring’s customers and the Apache and Tomcat projects as well.

With this in mind, here are the top 5 reasons why I think this new arrangement for Hyperic and Spring is good for all.

  1. Java. At its core, Hyperic is a java application. I haven’t seen a code audit recently, but would guess its 95% java. A lot of the projects such as Hibernate, ehCache and others that Hyperic uses, Spring has tremendous depth in and will help the Hyperic application grow. While Hyperic supports lots of technologies well, including .NET, I would guess that 80% of Hyperic’s install base uses it to manage Java. They may manage more than Java as well, but 80% of them have Java applications under management with Hyperic. Spring, while definitely a Java company has also been having big success in .NET and other environments. I think this will ensure that the Java interoperability in the overall data center will be more secure, stable and faster to develop and deploy and that Hyperic’s coverage and capabilities will only expand.
  2. People. Between working with the Spring engineers on the OEM project, and the Covalent folks on the original Hyperic project, there really isn’t a better marriage out there for Hyperic to hit the ground running and develop really cool products fast. At Siebel, I went through several aquisitions. They were long and painful, mostly because whole new groups of people were inserted into a product development team that didn’t understand the core technologies. Not so here at all. Also, worth noting, all of Hyperic will stay intact in engineering, sales and support. Javier included, and in fact – he’s going to get back to working on product, and that dude has a lot of pent up creativity he is about to unleash. This will be good.
  3. Open Source. Building on the previous statement, a lot of the core dependencies for the project are based in open source. These components, like MySQL, Tomcat, Hibernate and others have a wide pool of talent in the marketplace already. Sure, the specific applications may be slightly different, but there is a lot of shared knowledge here, so it usually isn’t too hard to get anyone not familiar with the project familiar quickly. I assume its the same for the other Spring products as well.
  4. Groovy and Grails. Hyperic added some new functionality about a year ago to do live scripting and integration using Groovy. Our engineers loved it. So did Hyperic users. In fact, they’re regularly asking when Hyperic is going to provide native management for Groovy. Groovy is growing amazing popularity in the cloud, and Hyperic has been focused on this area for a while now. Spring bought the Groovy company a year and a half ago. While likely not the intent to just marry Groovy and Hyperic, I think that it makes the likelihood that Hyperic plays even better with Groovy soon.
  5. Money. Two years ago, I cringed while watching Javier be interviewed at JavaOne by Cote. I cringed at the part where Javier was saying that Hyperic is the cash register of open source. I shouldn’t have cringed. It was true. Open Source companies are making money for the most part by selling either two things – better manageability and predictability of their software, or better intelligence analytics. So they looked to OEM either a management platform like Hyperic, or a reporting/analytics platform like JasperSoft. Hyperic OEMed JasperSoft with its Operations IQ product. Spring now has full reign for both of these very lucrative offerings to their customers.

All in all, I am feeling pretty proud today of my fellow Hypericans: Javier, Morgan, Sachs, Doug, Charles, Trav, Marty, Chip and all the rest of the A-list team back there at 609 Mission Street. I may be far away, and no longer an employee, but I am feeling pumped about this new development and am excited to see how it unfolds. Who would’ve thought that the whole old gang of Covalent v1 would be back together again today?

Note: While I am a former employee of Hyperic, and they are a client, this note is entirely my own thoughts and not that of Hyperic. I, of course, was not part of the conversations of putting this deal together – nor do I know if I fully represented the opportunities here.