Reblog

Strangling Strategies

I first heard about the strangler metaphor from Martin Fowler’s blog. In that context the strangler was any feature added to an existing legacy system using more modern criteria or technologies with the goal of gradually replace the legacy codebase. It’s actually more a strategy than a classic pattern, in the sense that depending on the specific case the steps to move from an old to a new system can be drastically different.

Well, with great pleasure I attended Tyler’s presentation on JRuby on Rails yesterday night at the polyglot programmers user group. Tyler demonstrated the practical steps to gradually replace a web-based Java application (Struts in this case) with Rails. The entire operation can be almost transparent to the eyes of the customer, management and even the team. JRuby (but also Jython, Groovy or Clojure) are strangling enablers for the Java platform adding a complete new meaning to the “Application Strangler” strategy.

The general strategy, even if the implementation differs, consists of some basic principles:

• The strangling happens in stealth mode. The two souls of the application should be able to coexist as long as required for the migration to succeed. This means that whatever change is necessary, from the build mechanism to the source code, special care must be taken to leave the current system unaltered until all the dependencies are routed to the substituting piece.
  
• No unnecessary behavior duplication. You should try to avoid the situation where the same code exists written in different languages and used in different places if not for some short period of time. You don’t want to force the team to maintain the same thing twice (Tyler here made the good example of the header/footer of the web page, potentially available both in Rails and Struts).
  
• Onion rule: start peeling away the most external layers. Migration will be easier if there are no inbound dependencies on the target component. For example, serving portions of the web interface with Rails is easier than migrating the domain layer. Another strategy could be to start writing tests, specs, stories, scenarios, acceptances, integration or functional test with the new language.
  
• Always keep in mind the reason to “strangle”. Rails is strong on specific part of the development process (for example controller and view development) and can speed up the team. This doesn’t necessarily mean to move the model from Java/Hibernate to Ruby/ActiveRecord if it’s not adding too much value.
  
• Partial strangling. A corollary of the previous point: the two souls can coexist for ever. The “Use the best tool for the job” principle in practice.
  

In the project I’m working on, the test-first part is done on the Ruby side as well as acceptances. The compelling reason to do that is in my opinion the superior readability and conciseness of testing and mocking in Ruby which tends very easily to mutate into an internal DSL that fits the job. The build tool I’m using, Buildr, has the same nice nature plus being built on top of Maven (the good part of it!). At the same time the RSpec Story Runner which runs plain english stories and relative scenarios fills the automation gap between business analysts, developers and QA. The build automation system and the testing frameworks are for sure another good strangling point!

Take care!