Mapping Rails to Legacy Systems

Devon Jones, Architect of Web Systems, Vonage
Stephen Becker, Developer, Vonage

They’re going to talk about the way that they have integrated with their legacy systems.

Rails at Vonage

• Subscribe System
• VFax
• A bunch of internal things like Metrics Mole to show business people decision so that they can
• RESTful services

Last year facing a software crisis. Rapid customer growth led to software developed quickly and crufty.

Large projects are a problem. They try to do small programs and projects, deliver on the order of months not weeks, and have 1 or 2 features per app, with transparent interfaces so they can chain them together.

When you have a system that is hard to change eventually you decide to replace it. Traditionally you go with a long project trying to replace the old one and owing to scope creep you end up trying to do to many things. (Sound familiar to anyone? PAS?)

Working on a legacy system is like working on a car while it’s going 60.

He is citing the Standish Group study. This has got to be the most cited study ever.

Change gradually and consistenly because people fear change, the smaller a project is the less risk there is, allows for rapid course adjustments, and it shows success early and often which helps sell stakeholders.

He just quoted ESR from tAoUP which is funny because I was thinking how much what they are describing sounds like the unix way.

Forget code reuse look for program reuse. Simple, transparent interfaces like REST (or unix pipes) make it easy to debug, test, and chain programs together.

Ripping apart a lafre legacy EJB system.

1. Find what specific feature you need\
2. Wrap it in a RESTful interface
3. create a test suite for that RESTful interface.
4. Implement the RESTful service outside of the legacy system

Suggestion 1:

Use the system. See what features / services are used. Step through in a debugger until you find where the real logic is.

As soon as you find it drop a RESTful service around it and then you can build the rails front on that.

Now you can make the legacy code use the RESTful service.

Now you have enought understanding to build a Ruby functional test suite for the RESTful service. U

Use the functional test suite and JDBC logging to figure out what is done in the old DB.

Now you can tun off the old code. The rest of the legacy app is still there and is still crap, but represents future targets.

Active Record in Legacy DBs

• Database Degradation
• Documentation
• Nonstandard DB schemas
  • 8 different ways to represent false in the same column
  • terminated spelled 6 different ways in the same column
  • Dates stored as varchars
  • csv data in columns

You can define custom module methods to fix this. Exclude columns

User Interface Integration

• Transparent Proxy: Noodle, Transproxy and Squid - Less legacy change
• Single Sign On Keys - Alternately you can use SSO keys. - More legacy change

It worked at Vonage. They get more maintainable code out quicker, it’s well tested and has much fewer lines of code.

They repurpose old data. They have project tracking tools, test harnesses for java code written in rails,

Where does Rails fit?

• Rapid Prototyping. You need something small and quick this is the framework.
• Mission Typical tasks - Applications that are a little more forgiving, not quite “mission critical” things
• Cost analysis - Development time vs. hardware. Hardware is cheap, developers are expensive.

What are they working on: composite keys

Resources

Questions

What do they do with their DB?

What they try to do is create clean services, then when all DB clients are using the service they can clean up the data without fear of breaking existing apps.

In terms of risk management, does the slow migration force your hand in terms of design?

A little, you have to maintain compatibility with legacy services.

Are they working on a API. eg. can we get access to our voicemail

They’re working on it, but management isn’t sold quite yet.

How do they do SSO?

Most solutions aren’t very cross language / platform. They rolled their own. Simple, textual interface.

From a deployment operations perspective how do you deal with the many small apps?

Take a look at JRuby. You can use your existing deployment strategy by using WAR files. If you don’t want to push to J2EE. Use Capistrano.

My take: Automate everything and I imagine that you’ll be fine.

When a Rails app shares with a legacy how do you use fixtures?

His opinion is that you shouldn’t use fixtures for testing. He is in the mock camp because he doesn’t think that a fixture based test isn’t a unit test. If you want to use them have the DBA create a separate schema with the same structure but no data. Developer: suggests kissing DBA ass.

A lot of the issues with legacy work are building relationships and bringing people who control the legacy systems don’t want them to change.

Do you gather business rules or reverse engineer?

The code is the business rule. People get confused about rules, the code doesn’t.

How do you maintain business owner interest in infrastructure improvement?

Deliver early and often shows real benefit. Once you can show them that they can get features they want quick they won’t go back. Projects like this thrive on agility. They use two week development cycles. Ability to readjust priorities is a huge win.

Is there an online communithy around these issues

Enterprise Rails Yahoo group??