Hear the Enterprise RoR

January 30th, 2008
by Jeremy Thomas

rails.pngSusan Scrupski recently wrote about how the likes of Tim Bray feel that Ruby on Rails is a great option for the enterprise. I couldn’t agree more with Tim. I’ve been working closely with the framework in recent times and also built some demos with it back in my consulting days. Once I got over the differences between Java and Ruby I began to see the magic of how Rails makes it easy to build web pages, REST services and interact with databases. A decent programmer can stand up a Ruby on Rails app much quicker than he can a Java or .NET app. Period.

There are concerns, however, over RoR’s ability to scale. Last year, Alex Payne, developer at Twitter, was asked “How has Ruby on Rails been holding up to the increased load?”. One of the things Alex said was “All the convenience methods and syntactical sugar that
makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise”. In other words, “magic” = “slow”.

But these are issues that can be solved with conventional measures. David Heinemeier of loudthinking.com points out:

I’ve said it before, but it bears repeating: There’s nothing interesting about how Ruby on Rails scales. We’ve gone the easy route and merely followed what makes Yahoo!, LiveJournal, and other high-profile LAMP stacks scale high and mighty. Take state out of the application servers and push it to database/memcached/shared network drive (that’s the whole Shared Nothing thang). Use load balancers between your tiers, so you have load balancers -> web servers -> load balancers -> app servers -> load balancers -> database/memcached/shared network drive servers. (Past the entry point, load balancers can just be software, like haproxy). In a setup like that, you can add almost any number of web and app servers without changing a thing.

Ruby on Rails faces the same scalability issues as other frameworks. The solution to the problem, then, becomes relatively standard. Share session information, load balance web servers, load balance application servers.

And let’s face it, enterprise applications will never need to contend with as many users as a web site like Twitter does. The largest organizations have hundreds of thousands of people. Not millions (and viral web sites need to scale to millions).

Given the speed of development and agility of the framework, I Ruby on Rails apps will increasingly disseminate across next generation enterprises - enterprises looking to implement Enterprise 2.0.

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • BlinkList
  • digg
  • Reddit
Tagged With enterprise 2.0, RubyOnRails

4 Responses to “Hear the Enterprise RoR”

  1. surfast Says:
    January 31st, 2008 at 11:54 am

    Yes, Rails is a dream to develop in. You can get a small application running on your local machine in minutes however unless you are a unix guru getting that great new application into a hosting environment could take weeks. If you are thinking about building anything in ROR that will see the outside world don’t write a line of code until you have deployment covered, adding it at the end has me wishing I just built the thing in ASP.net!

  2. Sean Says:
    January 31st, 2008 at 4:29 pm

    Jeremy, great post. I have two questions though. I know ruby is easy to use and all, but considering the large amount of current apps now that is being developed on Java, how can Ruby take over Java in this space?

    Also, loadbalancers can solve the performance issue of Ruby. However, configuring loadbalancer (with regards to my one and only experience with loadbalancer in my previous project) seems like the biggest nightmare. One small error and the site comes crashing down. How viable is this option or is my only experience a bad one?

  3. Jeremy Thomas Says:
    January 31st, 2008 at 4:56 pm

    @surfast yes, deployment certainly can be an issue. There are toolkits that help with this (like Capistrano), but you’ll have to configure Ruby to run on Apache or Mongrel (and switch out the default MySQL driver to one compiled in C for the target OS).

    @Sean, I don’t necessarily think RoR will surpass J2EE, but I think it’ll take some of its market share. With that, J2EE apps will have scaling issues too. Load balancers are generally used to mitigate load with J2EE solutions as well.

  4. Paul Li Says:
    February 2nd, 2008 at 8:25 am

    @Sean, load balancers come in many varieties these days. On my past projects, I have come across both hardware and software load balancers. To be fair, they all have their own ’special’ ways of configuring, but they are getting much easier to manage.

    On the performance front, can I just say, tuning should be something that you just do regardless of the underlying language or framework, Period. For a web site, session management and replication, database pooling, thread pooling are typical areas to look out for. Or at least these are the areas I found problems in ;-)

Leave a Reply