skwpspace it’s pronounced ’scoop’. yan pritzker’s home on the web

Twitter opens the floodgates of FUD

TechCrunch is reporting on rumors that twitter is leaving Ruby on Rails. Of course the comment threads are covered by a heated debate by people either bashing RoR, suggesting their favorite language and platform as the ‘only possible solution’, or both. Nevermind that Friends For Sale, with 630k active daily users scales just fine on RoR. Let’s ignore that scribd and yellowpages.com use RoR and most developers would only dream of having the traffic these apps have.

Of course, only Enterprise Java scales, and we know this because the word Enterprise is right there in the name. Of course, the only platform you should consider is .NET because it has built in caching and hundreds of thousands of college graduates know it. Of course, you need to use PHP because Facebook is written in PHP and Facebook scales. The fallacy of these arguments should be painfully obvious, yet people are shouting these things as if they were gospel truth.

I’d like to offer here, the scalability manifesto. Please repeat these items aloud to yourself every time you want to say something about language X or framework Y not scaling.

The Scalability Manifesto

1. Scalability means the ability to handle increasing load by increasing resources.
2. Scalability does not mean being ‘fast’.
3. Choice of language does not guarantee scalability.
4. Hardware costs decrease exponentially, developer salaries do not.
5. Only you can make your system scale.

Trading performance for development time is generally not a good idea. It’s likely that by the time your application reaches serious traffic levels (if ever), hardware will cost half of what it did when you started. Now does spending twice as much dev time with a lower level language seem justified? Now this is not always the case, but my bet is if you do the math and realize your team of 4 Ruby hackers is doing what a team of 10 Java programmers used to do, you might conclude that linear performance gains due to language choice are not as relevant as hiring smart people who can get work done quickly, and design scalable systems.

There’s no such thing as a free lunch, and that includes scalability.

“The Scalability Manifesto”. Brilliant.
You should snag an appropriate domain name.

+1 to a website for this manifesto.

I hope more people come read this.

Sorry, I don’t agree with you… :)
I love RoR, but you simply can’t ignore some inherent flaws in ruby (and to a lesser extent rails) that make it harder to scale compared to php or other platforms. Ignoring these flaws, saying that scaling is “simply adding more hardware” as i’ve read somewhere else is untrue and sounds like fans scratching each other’s backs. If twitter does ditch rails, it would be totally understandable and does not mean they don’t know how to code or scale - simply that they chose the wrong platform for their service.

What flaws specifically are you referring to? I’m not saying there aren’t any, I’m just curious what they are. I also agree there is a tool for every job, and I’m not saying that RoR is the right one for twitter. I’m just trying to clarify that scalability and performance are very different things.

Scalability is never ’simply adding more hardware’, but the point is it’s never that simple regardless of platform. You have to design a careful architecture that scales. Most commonly this is done via the share-nothing model. If each of your processes shares nothing with the other processes, then you can increase your pool of rails processes (mongrels or whatever you have) and achieve a fairly linear performance gain. It’s not too different than what you’d do in any other platform. So what is preventing the scalability?

In twitter’s case there is more than RoR at play. The website is only a small part of the equation (probably the smallest). Most of the ‘work’ twitter does is pushing out notifications. This part of the system would have to be optimized to hell and Java and C should be employed where necessary. Distributing work using a messaging queue architecture, I assume. None of this stuff has anything to do with RoR..so…