Saturday, May 17, 2008

Scaling RoR when you're a Java developer

So I'm coming into a new situation and I can't afford to make dumb decisions based on my own experience and bias. The company has made a large and profitable investment in doing smallish websites using RoR. Problem: maintaining 50+ individually deployed websites (regardless of tech stack) is a drag, so I'm looking for ways to consolidate onto a single platform that can host multiple customer sites.

My hunch as I go into what a former co-worker described as "hardware is expensive-land" is that RoR scales via a "throw money at the train" algorithm. I'd like to be able to scale out layer by layer. Blah blah blah the point is, I am a java developer and there are more well-known patterns for scaling out large java web apps then there are for ruby. At a small company we need proven solutions that a) work and b) aren't too hard to do. The possible trajectories and migration paths at this time I see are:

  1. JRuby
  2. Grails
JRuby means I can dump RoR apps into a Java container and get some free clustering. More interestingly, I can transparently migrate RoR controllers onto Hibernate without having to refactor much - a testament to the greatness of the RoR separation of concerns.

Grails means I can move to an all Java platform using a very RoR-like idiom that will make life easier for the developers. Groovy 1.6 looks to have the performance problems of Groovy in the bag. It uses Hibernate, the one technology I feel like I have some strong knowledge of, strong intermediate if I were to use skier analogies.

Grails/Groovy books

Definitive Guide to Grails, Second Edition
Groovy Recipes

No comments: