Friction(less) Rails
I’ve been thinking quite a bit lately about solving problems at web scale, so I’ve been following the story of Twitter with quite a bit of interest. There was a bit of a flap recently when Josh Kenzer interviewed Twitter’s Alex Payne. Alex made some statements about the pain of doing very large scale scaling with Ruby on Rails that caused a bit of controversy:
Running on Rails has forced us to deal with scaling issues – issues that any growing site eventually contends with – far sooner than I think we would on another framework.
and:
None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.
and:
If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.
That is what I’d call “tough love”. Ruby on Rails fans may not want to hear about these things, but that doesn’t mean they aren’t real problems when you try to scale at a massive level like Twitter is doing.
Unfortunately but not too surprisedly, the initial reaction to these statements was pretty defensive. Since then, though, there has been a lot of good discussion of what it means to scale in Rails. The best discussion, though, has been from Ryan Tomayko, who says:
I picked up a word from Joe a few years back and find myself using it a lot: “friction.” When referring to framework and tooling, “friction” is a (subjective) measure of how much the tooling gets in your way when trying to solve a specific-case problem. I’ve come to evaluate frameworks based on two rough metrics: how far the framework goes in solving the general case problem out of the box and how little friction the framework creates when you have to solve the specific-case problem yourself. When a framework finds a balance between these two areas, we call it “well designed.”
Measured along these lines, there are portions of Rails that have a less than perfect balance but I don’t think multi-database connectivity is one of them. It seems to me that moving too far in one direction on this would cause lots of friction for moving in other directions. There just doesn’t seem like there’s a lot of general case to solve here when you dig into the details.
I love that quote on friction: it really captures the thing I like best about Rails. His entire article is well worth a read, both for the insights into good framework design and for the specific extensions he and his cohorts made to Rails to make it work for what they were doing. Great stuff and I hope the public conversation continues like this.
Shebanator 