Outside.in Scales Up with Engine Yard

Case Study

The Opportunity

Sometimes, even the best-laid plans can change. Or, in the case of Outside.in, take on a life of their own. In October 2006, the company launched a website aimed at aggregating local content for users. It quickly became much more: a virtual neighborhood collecting hyper-local news, blog posts, and other sources of information to get people connected with what was happening around them.

“The original site was built with a different architectural vision than what it ended up growing into. We needed to make changes at a fundamental level to enable the growth we wanted to see and to make the application work better, smarter, and faster,” said Cory Forsyth, Outside.in’s CTO.

This meant a major architectural overhaul. Forsyth thought it only made sense to look at options other than PHP, which was the original language the company used to build the site. The team considered several frameworks, including Ruby on Rails. “We wanted to use an established framework that would help us get more out of our programmers and spend less time on the actual upkeep of the framework itself,” said Forsyth.

The Solution

Although only one person on his team had had experience with Rails, Forsyth ultimately went with the emerging framework. “Rails was powerful and extensible and would do all the things we needed, so we made the switch.”

That switch came with its own challenges, as it required that the entire team quickly learn to use the framework while also learning the Ruby programming language. The team also had no margin for error in migrating their application from one language to another. The new code base had to do everything that the old code base could. Finally, Forsyth had to rethink their deployment strategy. The old application was hosted on Rackspace, but with the move to Rails, Forsyth felt that they needed better domain expertise in their hosting partner.

That’s where Engine Yard came in.

A month or so before the migration was complete, Forsyth began looking at hosting options. Engine Yard’s name came up in association with Ruby and Rails, so Outside.in talked with them.

“Engine Yard had a scaling path laid out that made sense,” said Forsyth. “We felt Engine Yard was focused on websites that had serious plans to scale. Which was, of course, what we intended to do. Even if we weren’t at that point, we still wanted an easy path to scale when we’re ready.”

Results

Outside.in launched its new Rails site in November 2007. With over 1 million unique visitors a month, the company has had to scale substantially to maintain excellent performance, from two slices to 10, and from two web servers to six. Throughout all this, Engine Yard has supported the Outside.in team.

“Engine Yard’s support team is actively involved. Rackspace had great support, but they didn’t help us at the code level,” Forsyth said. “In contrast, we can ask Engine Yard’s support team a lot of questions specific to our code. Plus, we’re in communication with them on daily basis, whether on IRC, the phone, or email. They make it easy to get in touch with them.”

Outside.in is reaching another scaling threshold and is considering investing in its own infrastructure. Though this would mean a possible move away from Engine Yard services, Forsyth notes, “We’ve had ongoing conversations with Engine Yard about what makes sense for our application and what the next big tier we may want to jump to. They truly have our best interests in mind.”

For those looking to Ruby or Rails for their applications, Forsyth has some advice. “Rails is not a magic bullet. It is a really good framework with some flaws, but all frameworks have flaws. It’s actually a good thing that Rails’ flaws are better known; you won’t get blindsided at an inconvenient stage in your development. Nor is the Ruby language itself going to be your bottleneck. You need to think harder about your architecture earlier on in the process and plan on scaling your application horizontally the way Engine Yard lets you do this with their slices.”