Ruby on Rails has been doing well since its introduction a few short years ago but has taken some criticism for not always scaling. Developers know there is always a right way and a wrong way to solve any problem and scaling Ruby on Rails is no different.
Gregg Pollack of the Rails Envy Podcast and envycasts has been taking on Ruby on Rails scaling topics with a series of podcasts, in cooperation with New Relic aptly called Scaling Rails. Gregg Pollack lives in Orlando, Florida where he produces educational media for his company, Rails Envy. He is very active in the Orlando Tech community, helping organize BarCampOrlando, the Orlando Ruby Users Group, and CoLab, Orlando’s first official co-working space.
InfoQ had the opportunity to talk with Gregg about the new screencasts and how they will help developers scale Ruby on Rails.
Robert Bazinet (RB) : I see the introduction of the envycasts series you started off with a scaling theme and now the new series Scaling Rails. Is this a coincidence?
Gregg Pollack (GP) : I realized a few months ago that I wanted to do some envycasts about Scaling Rails, but to get to the point I realized I should start with the basics, looking at Ruby. This is why I initially put out a “Scaling Ruby” envycast. The next envycast in the series was then supposed to be “Scaling Rails”, but I was lucky enough to find sponsorship with New Relic which allowed me to release it for free.
RB : What were the driving reasons for finally deciding to do the series Scaling Rails?
GP : There were several reasons:
- To give Rails developers all the information they need to successfully scale a Rails app. A developer may never need to use these techniques, but hopefully the videos will give them the confidence to tell their clients that they can create Rails applications which will handle millions of simultaneous users.
- To show developers from other languages how easy it is to scale a Rails application.
- To hopefully further discourage the perception which some enterprise companies still have that “Rails Can't Scale”. Now any Rails developer in this situation can point to the Scaling Rails screencasts and say “Rails can scale, and this is how”.
RB : How did you come up with the idea for envycasts and later pursuit of Scaling Rails?
GP : Two of my biggest passions are film production and web development. Envycasts gave me a way to combine these two passions and perhaps make enough money to feed my kids. I'm honestly not making a killing on these videos, I'd get paid more doing strictly contract work, but like I said, I love this stuff.
The goal of Envycasts is to provide educational video in an entertaining format.
RB : It seems New Relic has an interest in scaling Rails as your series is part of their Rails Lab. Would you elaborate in this relationship and what these screencasts are all about?
GP : New Relic has an interest in helping the Rails community grow, and encouraging enterprise adoption of the Rails framework. It just makes sense, they want more customers and one way to do with a small community like ours it is by investing in the community itself. We've seen Engine Yard do this in the past by investing in the Rubinius and Merb projects.
New Relic created the Rails Lab website to produce content centered around Rails Performance topics. They sponsored my videos so I could release them for free on Rails Lab.
RB : What do you see in the future of Rails being adopted by the enterprise? Do you see these screencasts as a way to help Rails get there?
GP : I'm slowly seeing more young developers inside large companies convincing management to use Rails on projects. It usually starts with internal applications, and slowly works it's way into production. I have little doubt we'll be seeing more big name companies over the next year releasing their own Rails applications into production.
Now is a great time to start using Rails, especially because of the economy. With Rails we can accomplish more with less code and the maintenance cost (at least in my experience) is much less then other languages and frameworks. Bigger companies that realize this sooner then others will have an easier time maintaining a competitive edge over their competition.
I'd like to hope that some developer out there might use these videos to convince their boss to use Rails on their next project. One can only hope.
RB : What do you have in store for future Rails screencasts on the topic of scaling Rails?
GP : I'm honestly not sure at this point, 13 episodes are out now:
- Episode #1 - Page Responsiveness
- Episode #2 - Page Caching
- Episode #3 - Cache Expiration
- Episode #4 - New Relic RPM
- Episode #5 - Advanced Page Caching
- Episode #6 - Action Caching
- Episode #7 - Fragment Caching
- Episode #8 - Memcached
- Episode #9 - Taylor Weibley & Databases
- Episode #10 - Client-side Caching
- Episode #11 - Advanced HTTP Caching
- Episode #12 - Jesse Newland & Deployment
- Episode #13 - Jim Gochee & Advanced RPM
RB : What are reasons some people get the impression Rails cannot scale?
GP : I think the majority of the bad press on scalability came from Twitter and Tech Crunch a few years ago. Twitter, as you probably know, is a messaging platform which can handle millions of requests per second. While Rails might be fine for the front end of a messaging platform like twitter, the back end infrastructure needs to be able to scale in ways that most web frameworks would not be able to handle out of the box.
Since twitter did have some scaling issues, many took this to be a sign that Ruby on Rails applications in general had scaling issues, which is clearly not the case.
RB : What advice would you give developers, starting to create Rails applications in their company, to create a scalable Rails application?
GP : Watch all my Scaling Rails screencasts! Shameless Self Promotion
Seriously though, learn how to take advantage many caching mechanisms Rails comes with out of the box. Install a server monitoring tool like New Relic's RPM so you can monitor your application in production. Use this information to figure out where your application is slow, and where to optimize.
Recently I've been seeing companies jump into memcached too soon. Don't start using memcached to store database objects before you've really taken the time to optimize your database queries.
Lastly, at the very start of project ensure you have time set aside in the launch schedule to “optimize the app” before you go live. Don't let anyone take that time away from you.
RB : What resources would you suggest, beyond the screencasts you create, to help developers create scalable applications?
GP : I suggest:
- Read Cal Henderson's book on “Building Scalable Websites”.
- Learn how to use YSlow and get straight A's.
- If you're a Ruby developer, read “Ilya Grigorik's blog”
- If you're a Rails developer, read the “Caching with Rails guide”
RB : What benefits do you see to enterprise developers to use Ruby and Ruby on Rails?
GP : Well.. this is out of the scope of what we've been talking about, but the biggest benefit of using Rails in the enterprise comes in the maintenance phase of a project.
- There is one common way to build a Rails application. This means you can add members to your team and you don't have to “get them up to speed”. This also means you have more security, if something happens to the firm who is building a Rails app for you, you can easily pickup and go to another firm.
- Ruby allows developers to be more productive, and write less code to do more stuff. This means there are going to be less bugs and it's going to be much easier to maintain. This also means it's easier to stay Agile, since changes simply require less work.
- Ruby code is also very expressive, meaning it's easy to read the code. What this again means, is that you're going to save money in the maintenance phase, because it's going to take less time to understand someone else's code.
RB : Gregg, thank you for taking the time to talk with me today.
Gregg Pollack is the co-host of the Rails Envy podcast and a member of the Rails Activist Team. Find all 13 episode of the Scaling Rails series at the Scaling Rails web site to download the screencasts and code samples.