Monday, June 27, 2005

Enterprise Ruby on Rails

[I recently had the following email exchange with a developer who was gracious enough to allow me to repost it here, appropriately anonymized of course. His questions are mostly italicized, my responses are mostly bold. I hope this gives you an idea of what we are facing in selling Ruby on Rails as a viable technology for corporate developers. - Obie]

What in particular would make Ruby on Rails a poor choice for a large production application? Speed? Scalability? Difficulty in dealing with complexity?

Speed and scalability are not issues as far as I’m concerned. I have discussed that topic in depth with David H. Hansson and I know the details of how they have the 37signals products setup. You can create clusters with HA-proxy providing the glue between tiers and load balancers in front divvying up incoming traffic. The great thing about working with process-based platforms like Ruby is that you scale them the same as Perl CGI apps and there is a lot of wisdom on how to do that effectively thanks to years and years of practice and open-source involvement by mega-traffic sites such as LiveJournal and Slashdot.

The issue of dealing with complexity is multi-faceted. I’ve heard of some guys (via IRC) working with dozens of model objects and controllers. I think one of the biggest concerns is how to effectively share the work between more than a couple of developers working closely together -- all a matter of communication and coordinating approaches. It is so easy to do the same thing in Ruby about twenty different ways that I assume (perhaps prematurely!?) that a large team would be difficult to manage.

What would make an application too large for Ruby on Rails? Basecamp (and even Backpack) seem to be decent in size (at least in target market, and Basecamp seems significant in the functionality provided).

They have significant functionality, but the scope is very focused. That is really the whole mentality behind "Web 2.0" style apps as I understand it: do one thing and do it very, very well.

Is it possible that if an application is too "large" for this sort of technology that perhaps it is poorly architected? Yes

(Some exceptions, perhaps few?) Probably

Is it possible that many web applications are far more complex and monolithic than they should be? Most definitely!

Perhaps web applications that provide large sets of functionality (like the one I work on) should be build(sic) as smaller semi-independent modules that depend either on the other modules for interoperability or on some shared data concepts? Sounds correct

As an example, we recently developed a new module for this site. The functional requirements actually turned out to be relatively basic. However, the project took significant time to spec and build, went over budget, and is not as easily maintainable as it should be given the depth of functionality provided. Much of the additional time spent seemed (in my opinion) due to trying to shoe-horn this new module into the existing massive structure of the site. The points of necessary interaction with existing site data were few. Seems like there might be a better way to develop new functionality while still maintaining the necessary interaction with the other areas of the site as well as the availability of the data for cross-module reporting?

Well, since you use Oracle, there are a lot of people that are saying that you could design Oracle updatable views as the data sources for your Ruby on Rails apps. As for determining the suitability of Ruby on Rails, it is a productive enough environment that you could probably reimplement one or more of the modules of your web application without much effort just to prove the concept.

Here is additional commentary on the topic that I shared with him later on...

Whytheluckystiff (silly name, but famous author in Ruby-land) discusses Ruby’s memory model in more depth than has been attempted before. A small, highly-competent team of developers can be very productive with RoR and still be mindful of things like respecting memory consumption – a larger team probably not. Actually, I was thinking of my experience on large enterprise app development based on J2EE and the same holds true! So the real barriers to adoption of Ruby on Rails are probably 1) it’s new 2) the productivity factor makes it a disruptive technology in most corporate settings.