Home arrow Ruby-on-Rails arrow Why LinkedIn Switched from Ruby on Rails

Why LinkedIn Switched from Ruby on Rails

Quite some time ago, professional networking website LinkedIn moved the back-end infrastructure of its mobile site and applications from Ruby on Rails to Node.js. The company made this change for performance and scalability reasons. Does that mean that RoR is a bad idea for mobile services? Not exactly.

Author Info:
By: Terri Wells
Rating: 5 stars5 stars5 stars5 stars5 stars / 1
October 09, 2012

print this article

Quite some time ago, professional networking website LinkedIn moved the back-end infrastructure of its mobile site and applications from Ruby on Rails to Node.js. The company made this change for performance and scalability reasons. Does that mean that RoR is a bad idea for mobile services? Not exactly.

To understand why LinkedIn made the move, it helps to know why they were using Ruby on Rails for their mobile services in the first place. For that, we need to go back to about 2008 or 2009, and hear what someone who worked on LinkedIn's team at the time has to say about the situation.

Enter Ikai Lan. Lan was part of a software engineering team that built things for LinkedIn outside of the standard Java stack.  The team's purpose was to build new features more quickly than the company's then-standard six-week iteration cycle. As Lan explained, the group's second major project “was m.linkedin.com, a mobile web client for LinkedIn that would be one of the major clients of our fledgling API server...we figured that we could eat our own dogfood and build out LinkedIn for mobile phones with browsers. This is 2008, mind you. The iPhone just came out, and it was a very Blackberry world.”

The group chose Ruby on Rails 1.2 for their stack, and used Mongrel as their deployment technology. This was cutting edge in 2008, but Mongrel brought with it one major problem: it's single-threaded. “It was deemed that the cost of shipping fast was more important than CPU efficiency, a choice I agreed with,” Lan explained. Right around then, the iPhone SDK shipped, and the team decided to build an app for the mobile device – thus “we inadvertently became the mobile team.” Their Rails servers would also handle the new app “and any other rich mobile client we'd end up building.”

Now the mobile services for LinkedIn were hosted outside of the main data centers. What did this mean? Every time a user accessed a mobile service from an iPhone, they went through m.linkedin.com, running on Rails, to LinkedIn's API. That might not sound like a big deal, but as Lan explained, “That's a cross data center request, guys. Running on single-threaded Rails servers (every request blocked the entire process), running Mongrel, leaking memory like a sieve...” Even worse, the Rails server “was little more than a proxy.”

Something had to give. Lan found promise in Jruby, but “the engineering manager at the time ruled in favor of Phusion Passenger,” which offered the team an easier port than Jruby. Not long after that, Lan left LinkedIn.

In fact, LinkedIn director of mobile engineering Kirin Prasad gave Ars Technica a number of reasons for the switch to Node.js from Ruby on Rails. Prasad notes that in its vision for its mobile services, LinkedIn values speed, ease of use, and reliability – in that order. Given that background, Node.js showed its superiority to the company's Ruby on Rails setup in a number of ways.

First, Node.js fulfilled the need for speed. It was up to 20 times faster than Rails in certain situations. Second, it scales well; Node.js needed only three servers to handle the same traffic for which Rails used 30, leaving room for a massive amount of growth. And third, moving to Node.js let LinkedIn deploy some of its resources – in the form of JavaScript programmers – more efficiently. In fact, the front-end JavaScript team merged with the back-end coding team.

So while Node.js is a better fit for what LinkedIn is trying to accomplish with its mobile services now, it isn't necessarily valid to say that modern Rails failed the professional networking site – remember how old that original stack was, and that it was never built with the intention of doing the job it ended up doing. As Lan warns, “Don't assume that you must build your next technology using node.js. It was definitely a better fit than Ruby on Rails for what the mobile server ended up doing, but it is not a performance panacea. You're comparing a lower level server to a full stack framework.” 

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

All Ruby-on-Rails Tutorials
More By Terri Wells

blog comments powered by Disqus

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2014 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials

antalya escort escort antalya antalya escortlari antalya escort bayan