Computing

Cloud Computing and Ruby: Interviewing Hampton Catlin

By Michael Morin, About.com Guide

See More About

Why are Ruby and cloud computing a good match? Basically: why Ruby? :

Why are cloud computing and Ruby on Rails a good match? Let's hear what Hampton Catlin, author of HAML and Wikipedia's head Ruby/mobile architect has to say!

Hampton Catlin: Ruby is slightly more computationally expensive than other languages, and having easy resource expansion available can cure a lot of the "What if we get on the NYT?" scares of business people. If PHP is 10% faster, that no longer matters when you can scale at that rate. If you were on one server, perhaps you could argue that 10% increase in capacity would be important.

And Rails?:

HC:Rails is a particularly good match for cloud computing because of its share-nothing architecture. You can toss off new instances of an application and it will just being to run. It has less to do with Ruby itself, but more to do with smart architectural decisions. I mean, of course Ruby is known as having a high developer productivity rate and that's always good for business. And the cloud helps most business concerns about scaling.

Are there certain applications you think run better in Ruby?:

HC:I would say that 99% of web applications are a good fit for Rails. At Wikipedia Mobile, we are using Merb, because it's one of the few instances where that 2% speed increase might matter. The possible traffic numbers are ridiculously high, so we had to hedge our bets. And I did other things like choose not to use a traditional local database. The application is purely run on Passenger instances. Makes scaling very, very easy. At this point, we are handling about 120,000 hits a day and currently have no caching enabled. At that traffic level, our server has stayed at about 1% load. I'm extremely proud of that fact.

What support is provided for code migration when there are major updates?:

HC:Mostly it's keeping up with the latest features and remembering what your application does. Of course, many people focus on TDD to help with those kinds of transitions, but I mostly just read through the code looking for changes. It works pretty well. Just the other day, I upgraded a pre-Rails 1.0 app to Rails 2.3 and it was rather painless. I just read through the code and upgraded when I saw something. Most of the core stuff hasn't changed that much. I mean, has_many still means has_many. Mostly its new APIs that would have made the code easier to write initially.

Scalability has been a concern about Rails. Can these concerns be put to rest?:

HC: I absolutely think so [concerns can be put to rest]. It's a ridiculous argument from the start. People act like Rails is slow. It's not slow at all. In fact, it's incredibly fast. It's more your programming decisions that change things. When I talk about PHP being 10% faster, that's only for pure code. That's a "Hello, World!" example. Once you start mixing in DB queries and computation, things even out a lot. PHP doesn't make your SQL request any faster. Nor does it make your image processing any faster. Nor does it make image downloading any faster. These things make up a majority of the processing time.

Can you address the scalability issue more?:

HC: I think in reality, you'd find a complex Rails site to be only 1% slower than PHP... and in some instances faster. Why? Because Rails uses repeatable and simplified design patterns. Doing any improvements on the site (like optimizations!) are far easier in Rails than they are in PHP. Frameworkless PHP is the thing that is the fastest, but it ends up being code soup. It's what we used to do in 1997... and God help you if you have to optimize one of those sites.

So, if scalability isn't an issue, what's important?:

HC: What's most important is making good architectural decisions. You can make those mistakes on any platform and those are going to be your real scaling costs. Also, avoiding the "big re-write". The big rewrite is systemic in development. Many clients I've worked with are always looking to that "next version in the sky" and it's a horrible mistake.

Why?:

HC: Like it or not, the architecture you start with is most likely the code you will end up with. You can re-write components, but having components requires a good initial architecture. You can upgrade certain areas, but never, ever go in and do a big re-write. Its a time and money hole. Rails helps you avoid those, and can save your company literally *millions* of dollars in the future (assuming success).

Michael Morin
Ruby Guide

Sign up for My Newsletter

Ruby