Last fall, software provider Hyperic started on a release plan that by all accounts is a major shift in infrastructure by migrating their EJB layer to Spring 3.0 and their internal server to Apache Tomcat. Originally built in 2002, and released as open source in 2006, the Hyperic software, a web infrastructure monitoring and management application, helps some of the largest web shops in the world monitor and manage their production web applications. For any well established software, such a fundemental change to the application architecture is surely not a decision that was made lightly.
The obvious answer is to follow the proven mantra of eating your own dog food. In 2009, Hyperic was acquired by SpringSource, who has significant investment in both their flagship product Spring and the Apache Tomcat, through their commercial distribution of Tomcat, vFabric tc Server, and the number of Tomcat committers and experts employed directly by the company. By adopting the "company standards", they have better access to engineering support and follow software best practices of using their products just like their customers do.
However, with such an established code base and number of production customers, a shift of this magnitude is bound to delay the development of new features and potentially bug fixes, which are critical improvements needed to keep customers happy. This type of a decision therefore needs to translate quickly into financial or customer benefit.
So why the change? The answer is the Hyperic engineering team wanted to move towards lean software development, a system of development processes popular with the Agile development community. The result of the move would allow future development and bug fixes of the product to happen more quickly through simpler configuration, reduced code complexity, decreased application start time, and faster debugging process which improves the maintainability, testibility, and reliability and their Hyperic HQ 4.5 software, which was released this month. In essence, a temporary delay on a stable product release would quickly pay dividends to their development costs and ultimately provide faster development of features for their customers.
For more information on the rationale, and a detailed walk through of the migration itself, check out the complete webinar that Hyperic technical lead, Jennifer Hickey originally delivered at the SpringOne 2GX conference held in Chicago in October. A link to an audio recording of her presentation with her original slides can be found in the Knowledge Based section of the Tomcat Community here: Hyperic's Migration to Spring and Apache Tomcat Case Study presentation.
It's not exactly accurate to use words like "legacy" when describing systems like IBM's i5 (it will always be the AS/400 to me). Our "legacy" systems are so critical to our ($1B) business it's not an overstatement to say that our restaurants could not transact business without them. The simple majority of our development time, energy, and money is spent writing new RPG code, introducing new green screen applications, and finding new ways to make the 400 work with the rest of our expanding private cloud infrastructure. Calling something legacy has usually implied that newer systems are taking the place of the "old" way of doing things. I suppose you could say that programmers use the word "legacy" interchangeably with "obsolete".
Our AS/400 is not going away. For that reason, it's silly to call it obsolete.
I've gotten some great feedback from the session on private cloud infrastructures I did at this year's SpringOne 2GX in Chicago. People are very interested in how these traditional systems can work with the new cloud services many are introducing into their enterprise. Plenty of organizations have decades of business knowledge and data tied up in "legacy" systems and they want to know how in the world they can get a fancy new cloud application server like tc Server to talk to their AS/400 (through more than SQL and JDBC).
Popular Links