On Twitter, Rails, and Community
Posted by kev Sun, 15 Apr 2007 20:13:00 GMT
An interview by a twitter developer has gotten a good deal of press lately. For many, it has reawakened the giant that is the “does Rails scale” debate, and others feel compelled to defend the framework.
The problem with Rails isn’t that Ruby is slow. It’s also not that Rails is slow, or big, or bloated, or doesn’t scale. The problem isn’t that Rails doesn’t support multiple databases or composite keys out of the box. The problem is that this is how the vocal minority in the community tends to respond to criticism.
So let’s all slow down and take a look at how we got here and what we can do to avoid it. That’s of course assuming we want to. Inflammatory posts certainly get lots of traffic, but I think Rails is in the spotlight enough we can actually talk like reasonable people and still get things done.
More after the jump.
Alex Payne inadvertently opened the flood gates when he gave a 5 question interview about working on Twitter, the highest traffic Rails app in deployment. When commenting on how Rails was scaling, he said:
The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.
Just so we’re all on the right track here, keep in mind that he didn’t say “Rails just doesn’t scale, there’s nothing you can do about it, abandon hope all ye who enter here”. Alex says that scaling Rails is more than a matter of money, it’s a matter of time as well.
Those who skimmed the article and didn’t actually listen to what Alex had to say began to use the interview as tinder for Anti-Rails posts and flamewars, and soon DHH responded. Here’s where the real problems begin. David turns Alex’s explanation for Twitter’s scaling problems into a discussion on blame (emph added):
Rails makes the act of developing such a pleasant experience that when you need to follow the same scaling path as every other shared-nothing stack, the contrast can feel stark. And perhaps it’s a natural reaction to feel a need to blame something for that contrast, however natural it is.
Second, when you work with open source and you discover new requirements not met by the software, it’s your shining opportunity to give something back. Rather than just sit around idle waiting for some vendor to fix your problems, you get the unique chance of being a steward of your own destiny.
Once the stress of having to deal with that in the moment subsides, I’m convinced that the team will grow beyond the blame game, get their hands dirty as full participants in an open source community, and contribute back their advances to the framework.
The conversation shifts from where bottlenecks come from when scaling Rails to “you’re saying it’s Rails’ fault, but it’s not”. This is where we start to slide down the slippery slope. It’s easy to argue about blame. David pulls out his “I’m not a vendor, I don’t owe you shit” speech, and says that because of the beauty of open source, Twitter is in charge of their own destiny.
He’s absolutely right. He’s also a big jerk about being right. David seems to imply that Twitter has been sitting on their hands, doing nothing, refusing to solve their own problems, and not contributing back to the community. This is false. It’s also completely beside the point.
Early in the discussion we started to imagine blame where it didn’t exist. Alex never says that Rails should support doing 11k requests a second. He simply said it doesn’t, which is something no one will dispute.
So, we’ve moved into rough territory, but someone goes and does something nice (Woo hoo!). Dr Nic writes a plugin to use multiple databases with Rails. Way cool. Really way cool. Awesome job Nic. This is the part of open source that I love, when people help each other just because it’s an interesting problem and they’re a nice person. Hugs and kittens all around.
DHH tosses down an ”I told you so”. David, what are you doing man? Yes, Dr Nic is awesome, and yes, Ruby is wondrously hackable, and yes, Rails allows plugins easily, BUT why do you keep beating this dead horse? No one said anything about a critical flaw. No one said Rails is inherently flawed and can never be adapted for high traffic sites. Just the opposite is true! Alex and the other guys at Twitter are those who are pushing Rails further than it’s ever gone. These are the pioneers. They’ve gotten to the hard part, and they’re still going, despite the difficulty. Really, does anyone think that sites at that load are running out of the box copies of Rails? It’s just not the case. That’s ok. The fact that Rails can be modified is one of its strengths. There’s no need to be defensive here. That’s the big problem we all need to face.
Before we post (or hit the enter button in IRC, or send off that email, or …) we all need to take a deep breath and figure out if there’s really any attack taking place.
I’m as guilty of violating this as anyone, and I’m sorry for it, but this needs to be what happens in the majority of cases, or we’re all going to turn into assholes.
There are some things we’re just going to need to get used to hearing.
Ruby and Rails are not as fast as some alternatives. But in most cases, it probably doesn’t matter. In some cases it does.
With Rails there is no vendor and no obligation to fix things. But just because Rails doesn’t do something out of the box doesn’t mean it’s broken. In fact, many things probably shouldn’t be “fixed” in Rails itself. We’ve got a wonderful plugin architecture just to fit that need.
Just because someone doesn’t contribute to a specific problem doesn’t mean they haven’t contributed to the community. Blaine Cook, one of the Twitter developers, recently released the awesome Jabber::Simple library, is a regular contributor at SF Ruby, and is going to be giving a talk at SVRC on making Twitter push the traffic it does. He even notes on his blog that Twitter is planning to release some of the tools they’ve developed to solve their particular problems.
There will always be growing pains. It’s natural. We’ll get through it. Let’s not tear ourselves apart in the process. Rails is what it is because of the community. This will continue to be a great ride with an interesting community doing exciting new things… as long as we don’t kill each other in the process.