There is an announcement about Twitter potentially moving away from the Ruby on Rails framework and looking for alternatives. In the article it suggests that Twitter is looking to migrate toward a Ruby only architecture. All this is no shock to anyone who has attempted designing a Rails-based application as a flagship product.

Every startup is focused on the same thing and that is getting a product out the door at a minimum amount of cost. The easiest way to ensure low cost is to cut down on physical development time. What I mean by physical development time is the actual time it takes to go from paper to final product. This is where Ruby on Rails has found its niche. Rails has been hailed as being the best thing since sliced bread when it comes to rapid development. I am not going to debate this fact because this is exactly why I use the framework myself. The highly debated topic I am here to weigh in on is the points of scalability and performance. These are exactly the same two points employees at Twitter have very publicly commented on.

Performance is a crucial component when designing an application as a flagship product. Startups need to always be mindful of laying the groundwork for high system loads. Keeping with Twitter, they developed on Ruby on Rails and when the site hit heavy load the site crashed for 3 days. This has lead to Twitter being publicly ridiculed to have the lowest uptime of any social networking site. It is very important to keep your startup in favor with the community because they are the ones who will make or break your business. Twitter was lucky that they recovered from these downtimes, but those are not the only problems that they faced.

After your application catches buzz among community members, the next issue you are faced with is scalability. Outside of its use on Twitter, Ruby on Rails has not been put to any real world tests in terms of scaling the technology. Now much of this can be allocated to the relatively young age of the framework in comparison to the alternatives. Many Rails zealots argue that PHP and other languages experienced these same problems when they first hit the market, however Rails has kept a unique approach to this problem. Twitter has tried asking the lead Rails developers for improvements to be made on the framework in terms of scalability. The reaction they received was less than helpful. Some even went so far as to say that even simple things like threading was said to be impossible. This was proved wrong by other framework like Merb which implemented it fairly simply. Not only does the Rails team tell users things are impossible, they even go as far to say that Twitter should do more to help. What honestly can they do? Twitter did not develop the framework, 37signals did. They are the ones that are posting the framework for public use and they should be the ones to tailor it to the broad applications that it is being used in.

So what does this really mean? Well I hope after reading this you may reconsider the idea of basing your next flagship product on Ruby on Rails. It is not the solution to all your development problems like some zealots tell you it is. Like every other language it has some major drawbacks. I personally believe that the drawbacks in terms of performance and scalability are large enough to deter me from using it for flagship products. However for proof of concept and small scale applications, Ruby on Rails is second to none in this arena. If this recommendation is ever going to change either 37signals needs to change its mentality toward the framework’s development or allow developers to trim the “fat” that has made its way into the framework.

I would just like to say that it is not all the Rails’ teams fault. It also is attributed to the fact Ruby is an interpreted language which makes it inherently slower than others and the fact the web servers like mongrel are still in their beginning fazes in terms of performance tuning. If you want some more light reading from Zed Shaw and another.