A “day in the life” - why Hydra?
Thursday, February 5th, 2009To understand what a technology does and why someone might want to use it, I think it’s helpful to compare what life was like before and after using it.
Like when Blackberry came out with their first full PDA version. My “day in the life” before that was that I had a paper planner that I used to track my contacts, to-dos and notes. It was bulky and I frequently didn’t have what i needed when I needed it. If I lost it I was S.O.L. My “day in the life after” is that I have my personal data with me all the time and it’s always backed up so I don’t have to worry about losing it.
People often ask me what Hydra is, and I say something like “it’s an integrated development and deployment framework for C++ and Java services.” This is accurate, but doesn’t really give a good picture (and I’m a visual guy, I like pictures).
So here is my “day in the life” from a software engineer or architect’s perspective - before and after Hydra:
Before Hydra:
- I have an application that has been around for a while, written mostly in C++ code. I prefer the power of the language and I don’t want to rewrite it, but it takes a lot more development time to maintain and enhance this application than if it were written in another language like Java.
- The development team mostly uses command shell editors and a custom build environment, which is a steep learning curve and productivity sink for the more junior engineers.
- Our deployment environment works, but we have had to cobble together different software, some commercial and some open source, to make it all work. It’s hard to maintain and upgrade and I’d like to simplify the environment and reduce the number of vendors that I work with.
After Hydra:
- Once the development team starting using the Hydra IDE in Eclipse, they became much more productive both with C++ and Java code and it’s all in one tool. The automatic code generation saves a lot of the ‘grunt work’ and it’s easier to debug, test and redeploy, shortening our dev cycles - this is huge in supporting our move to Agile Methodology.
- The Hydra runtime hosts both C++ and Java services in the same process so I don’t have to pay the performance cost of web services when they’re on the same server. I can use BPEL to orchestrate the services, but I don’t have to. Plus, I know that the whole thing is deployed to a scalable service grid that I can reconfigure as my requirements change.
- In addition, it’s a single, integrated environment. I can add other components if I want to, and the architecture is much cleaner and easier to maintain and extend. It’s based on web services and SOA standards (WSDL, SCA, etc.) so I have some protection from vendor lock-in. And I’m closer to having “one throat to choke” with my vendor when I need something.
In all, we’ve reduced our development effort, so we can do more with less and get releases out faster. This has saved the company money and makes our team look better.
