I know Robert Dempsey personally. He’s always struck me as a smart guy, he’s fun to be around and he’s definitely passionate about what he does. What he does is, of course, Ruby on Rails. Well, so do I.
Robert’s latest blog post asks if Twitter damaged Rails reputation with all it’s downtime etc. He comes to the conclusion that it probably didn’t, but he also says that, as so many have, the Ruby scaling problem is a moot one.
“ZDNet had a great article on LinkedIn using Rails for a Facebook app that serves 1B pageviews/month, which is on the first page of “ruby on rails” search results, along with a number of articles saying that Rails can scale and to not use Twitter as the benchmark.”
Here we go again. Despite the public perception that Twitter is a simple application that stores messages in a database and receives them on demand, it’s not. It’s a true real world style application that tackles the n-squared complexity problem (posting 1 message updates n friends and followers that in turn updates their main pages with messages for their n friends and followers to see). It’s also got a TON of users. BumperSticker, the application Robert is talking about serves a single result to 27 million views a day, or 300 a second, and to do so it needs to run on 25 (yes, 25) servers.
You can scale anything. Yes you can scale Ruby on Rails applications. The problem with scaling Rails, and this is where all the anti-Rails venom comes from is the effort and investment it takes. It shouldn’t take 25 servers to handle 300 or so hits a second. That’s an obscene investment. That this is being touted as a major indicator of the enterprise readiness of Ruby on Rails is, quite frankly, sick.
I love Ruby on Rails – that’s why I took a job working with it and leading a major Web 2.0 team using it. But it’s broken. There needs to be a concerted effort now not to keep adding in support for the latest buzzwords but to instead rearchitect the whole shebang to actually do what enterprises expect of it right out of the box.
When Ruby on Rails performance hits Python-Django/Php levels on a single machine with a real world application without requiring developers to jump through hoops to do it, then the performance argument is moot, not before.
The best applications are those which hide the underlying complexity. As you rightly point out, Twitter is definitely one of those. With 2,145,461+ users (according to TwitDir) all posting messages that go to at least 10 friends, that’s 21,454,610 messages a day, at a minimum. Then you get folks like me that tweet at least 3 to 5 times per day, and also have their blog post to Twitter as well. And if that wasn’t enough, you have the Tweets coming in via the web, IM, and SMS. That’s a lot of messages from a number of sources.
I do agree that the one barrier to mass Rails adoption (Rails is in the enterprise already BTW) is the amount of hardware required to scale an application. Rails, and Ruby, are well on their way to kicking down that barrier.
Comment by Robert Dempsey — July 19, 2008 @ 9:12 am |
That’s great. As I just said in a comment on the other post on this subject, I’m not saying it all has to change because it sucks. Rails is an awesome framework and has really changed the landscape for the better when it comes to web development. Even Microsoft are now weighing in on the whole deal with their ASP.NET MVC framework, and it borrows heavily from Rails.
No, the reason I said it needs to change, the reason it needs to get better, and fast, is the widespread adoption of it. With so many people relying on it it’s time for the core committers to step up and drive this thing where it needs to be. Otherwise you hit the down side of the Gartner Hype curve and reality will set in destroying all the hard work the Rails community has done in getting it where it is today.
Comment by pwrighta — July 19, 2008 @ 9:47 pm |
Though I’m inclined to agree with you on most of your points, a lot of people spend so much time concentrating on the language (or worse the framework) that they miss the obvious. A great majority of the bottleneck for an application that services massive amounts of requests is how it’s tied to it’s data. Most people spend so much time figuring out how to engineer something to work in a particular platform that little to no care is taken in data management. Careful and concise planning of the data you are going to gather and use, as well as planning out how that data is normalized, stored, and linked together is just as import if not more so than the implementation of the application itself. Thinking outside the box of standard ‘model’ thinking and thinking more along the lines of ‘how am I going to use this data and how do I make it scale if I’ve got 1 million records’ builds an excellent foundation that the rest of your application will rest on.
Obviously the front end is important but you can’t really begin to tie down where your loose ends are if the ground is coming out from underneath you.
Comment by Trevor — July 19, 2008 @ 11:19 pm |