Mapping Rails to Legacy Systems by Stephen Becker, Devon Jones

I liked this talk. A Vonage architect and a senior developer talked about how they use Rails in Vonage. They use it a lot, which gives those of us chained to an enterprise paycheck great hope. This was a nice practical guide on how to intelligently use Rails in an enterprise. Here are the highlights:

You “must transform legacy app into small programs with transparent interfaces.” Change gradually and consistently because:
– People fear change
– Small projects are low risk
– You can adjust course rapidly
– You can show success early and often

Do small programs and projects; use transparent interfaces.

Hand-raising poll!
How many maintaining J2EE systems? 10%
How many hate it? Same 10%

Don’t rewrite: whole-scale enterprise legacy app replacement tends towards bloat. “Like working on a car while traveling at 60 mph.” So don’t tackle them in very small projects. The Standish Group did a survey: large projects tend to fail.

Write small programs. J2EE transforms small apps into one big app (ain’t that the truth!). Instead of reusing code, create simple programs with flexible interfaces.

Use transparent interfaces like REST
– Design for visibility and consumption, inspection, and debugging
– Interface inputs results in a predictable and dependable output
– This allows for easy re-use

How to rip apart the system
– Wrap features in simple RESTful servers
– Create a functional test suite

There are many systems in prod today that no one understands, so you need to identify a choke point for your feature. Start by creating a RESTful servlet that calls down into your DAO or service classes or whatever. Your new shiny Rails apps can call that. Use functional test suite and JDBC logging to map possible endpoints.

How to cope with bad database design? Databases degrade over time, just like code: no documentation; nonstandard database schema.

The speaker gives examples of eight different ways to represent ‘false’ in the same database column, dates stored as text, comma-separated values. The audience thinks this is funny, odd stuff. Look pretty familiar to me!

Did it work at Vonage? Yes.
– Quick time to market
– Maintainable code
– Now have tests
– Reduced lines of code

Where Does Rails fit?
– Rapid prototype
– Mission-typical tasks when performance and reliability aren’t as critical
– Cost analysis: When developer time in more expensive than hardware

Q & A:
Vonage versions their interfaces in their services — the response include the version number. Vonage is developing a RESTful service for customers, so that you could check your voicemail vi a your Rails app.
How do you manage deployment of many small services instead of one big EAR? JRuby
Real business rules are in the old code. When you ask people how things work, they are often wrong.
Sell speed and control over features to management to win their support.

Leave a Reply

You must be logged in to post a comment.