Shebanator

Just a brief update to point to some more good discussion on the issues with scaling Twitter to handle its load better, as discussed in my earlier post on Friction(less) Rails. The first thing I wanted to point out is that a lot of people have called Twitter’s purported load into question. The original source for the 11,000 requests/second number was DHH’s original post as far as I can tell. That’s a heck of a lot of load, and as others have pointed out, its a nice problem to have. Jens Alfke of Apple has written a nice post describing the problem and ways to handle it that do not involve databases. Its an interesting read, and the comments are worth a look as well.

Another article worth reading is by Peter Bell. In it, he reflects on the tone of the conversation to date and thinks about the appropriateness of Rails for the applications it is being used for. I don’t actually agree with him but its an interesting point of view:

Simple apps with huge traffic requirements needs different engineering choices that complex enterprise apps that may have lower loads but higher complexities and maintenance burdens. When I look at an app like twitter (which is when it comes down to it, a submit form, a list display and an API along with some really interesting scaling challenges) I’m not sure Ruby or Rails would be the ideal tools. I’m not sure what language has the very best support for the highest and most robust levels of performance and scalability, but I’m guessing whatever it is would be the perfect choice – even if it meant it took you a week instead of a day to code the form, the API and the list (I know it is a little more than that, but I think we all know it doesn’t need to be TOO much more than that – it isn’t exactly an insurance quoting app or something).

As with anything cool and new (remember when Java was the *it* language?!) Ruby and Rails are being widely misused. I am not convinced that all of the Web 2.0 start ups selecting Ruby have picked the bet tool – they’ve picked the coolest one. However, cool tools bring the smartest programmers so it still may be a smart decision – even if the language and framework has problems, at least choosing them means you can more easily get the most innovative programmers to work on your problems, and just like in Venture Capital where a good team trumps a good idea, in programming a good coder trumps a good language.

Once again, I want to commend people for turning the conversation in a more positive direction. Its been a great read.

~ by Andrew Shebanow on 19Apr07.

Posted in Dynamic Languages
Tags: Scalability