Rails can’t scale alone.

I was reading a blog post which talked about a how Linkedin scaled their Rails Facebook app, Bumpersticker, to 1 billion page views per month on Joyent’s cloud computing platform. You can find a somewhat techie explaination of how it was done here.

To summarize their video, they used F5 load balancers to serve the majority of the page views as static content. So what did Rails do exactly? It managed the F5 cache. Thats pretty much it.

They scaled Bumpersticker by not using disks, making the dynamic content as static as possible, and pushing the content close to the client with F5. This kind of architecture is how scaling web applications has been done since long before Rails came to be. You can do it in PHP, Java etc. etc. Linkedin realized the only way to scale Rails was to use it as little as possible to serve their requests.

Bumpersticker’s story is not about Rails, its a testament to Joyent’s cloud computing platform and F5. So why use Rails? With Rails you can spend 10% of the time creating the app, 80% of the time scaling it, and 10% of the time marketing how Rails scales. Rails lack of performance makes you think about scaling earlier than you would on another platform. This is a GOOD thing. Some call it pre-optimizing, I call it capacity planning.

Instead of saying Rails scales, we should say that Rails makes it easy to scale by simply integrating with other, more scalable pieces of software. This is why I use Rails, no matter how many people bash Twitter for using it. Enough reading, go scale something.