Social Glass

Susan 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.

I’m a Java and C# guy. I’ve grown to be very comfortable with the two languages and associated frameworks (J2EE, ASP.NET), and can write programs that at least compile in each without having to search through the internet for examples. Hence my hesitation to learn Ruby - the language required for me to indulge in Ruby on Rails. But everybody’s doing it, and I don’t want to be left behind.

I decided to build a Ruby on Rails-based enterprise search application leveraging the Google Search Appliance (GSA) REST API. My aim was to show that A) Ruby on Rails is an agile framework leading to quick application development and B) the extensibility of the Search API (being that it can be leveraged from virtually any programming framework).

Here’s what I did:

I created controller class called Search Controller that manages the API invocation. This is done in an action handler method called on_search. This method invokes the GSA API, then converts the XML response into a REXML::Document object (part of the Ruby on Rails library.

url_escape is a nifty little method I found here that converts a search term like, say “technology integration” into “technology%20integration”. If you don’t do this things will break. params[:query] contains the search term the user enters into the search box on my search.rhtml page. Last the @search_results object is stored in the session and is a container for a collection of search results plus some global information about the search (like result_count and search_time). This object is bound back to my search.rhtml page to display the search results.
Next, I had to pull relevant information out of the XML response and add it to user-friendly objects that are then used to display the results on the view:

This method leverages ‘rexml/document’ to parse XML, i.e. search_response.elements[”GSP/RES/M”].text. “GSP” is the root node in the GSA XML API response document, and in this example I’m pulling out the result count, appropriately called “M”, inside the “RES” element under the document root. Parsing continues where I iterate through each search result, pull out the relevant information (snippet, url, title), add it to a SearchResult object, then add said object to the results collection in the SearchResults object (which, again, is stored in the session).

That’s it. In two quick and easy methods I can invoke the GSA XML API and parse its response into usable objects that I bind to my view. There is a lot that I’m not doing (i.e. good error handling), but I’ve at least proven what I wanted to. I’ve done this before in Java, and it took me less time to do it in Ruby even though I was learning the framework as I went.

I love Ruby on Rails.

I find it interesting as a blogger that, several months after a post is written, I get a flurry of comments on it. One tends to think that people only read the latest posts, but the evidence seems to contradict this perception.

Anyway, I found the recent post at rc3.org about RubyonRails being slow very interesting. I posted a few months ago about Java’s ability to scale with the long tail and recently received some well put comments indicating that the speed of Java is just fine, and that speed issues are generally caused by bad architecture. I argued that the popularity of PHP and Rails over Java in the Web 2.0 space seemed to show that those languages/platforms were perceived to scale well with the long tail (whereas Java seems to be king inside the Enterprise, which tends to have a much lower user base).  It seems that, at least with Ruby on Rails, the perception was based more on hype than fact.
Twitter’s recent popularity has been a good Stress and Volume Testing ground for Rails, which is a relatively new platform, and it seems that Rails is much slower than Java, PHP or Python platforms. This idea is raised at rc3.org, where Rafe Colburn writes:

I do wonder, though, if this kind of information [Twitter’s statement that Rails is slow] is going to push some startups over to PHP or Java, even if they’d prefer the development efficiencies offered by Rails.

I’m pulling for Java.

There’s been a lot of discussion about 37 Signal’s Basecamp over the past few months. I was curious, and from a timing perspective it just so happened that I was leading up a new project, so I went over to the site and created a new account. I’ve got a team of about 5 or 6 young and enthusiastic people working for me on the Strategy phase and the first thing I did was set them up. The second thing I did was migrate the Milestones from my project plan to Basecamp, and I also added a few TODOs.

Within about an hour my RSS aggregator was buzzing with updates. My team started posting messages (blogging), comments and content through the Writeboard (kind of like a wiki).

“Is this Enterprise 2.0?”, I asked myself.

Not quite, but close.

Basecamp is perhaps more structured than I’d expect an Enterprise 2.0 solution to be as it’s centered around project management (the notion of “Milestone” and “TODO” seems to me to be project oriented). But the collaboration and capture of tacit knowledge elements are certainly there, and the signals, boy do I love the signals. Maybe we can call this “Project 2.0″.

Anyway, I think the folks at 37 Signals have done a great job and I’m eager to try out their other products.

I wrote a post a few weeks ago about styling JEE (aka J2EE, some people can’t shake the “2″ even though we’re up to Java version 5 now) applications to give them a web 2.0 look and feel. Since then I got to thinking about JEE and whether or not it’s really relevant to the Web 2.0 world.

The issue is scalability.

I’ve spent the better part of my career with my head down, headphones on, techno music thumping, banging out J2EE-based (and some .NET) EAI solutions for large enterprises. These applications, at best, were scoped to target a user base of 10,000, and we never expected to have more than a couple hundred concurrent web-based user sessions.

Contrast that to google.com which deals with a couple million concurrent user sessions. And I know google.com is not JEE-based. It’s likely built with a light-weight scripting language (probably Pearl or Python give my experience with Google and their enterprise applications) with a lot of load-balanced servers behind it.

I haven’t done any official research, but in my experience most of the web 2.0 sites I’ve come across have not been JEE-based either. Most seem to run PHP (digg.com). Some seem to run Ruby on Rails. There’s one web 2.0 site that I know of that’s run on the JEE platform, and that’s zoho.com (the “.do” at the end of some of the links on zoho.com, i.e. http://wiki.zoho.com/jsp/ wikilogin.jsp?targetURL=%2Fregister.do, is a “verb” in Struts, an opensource JEE model view controller from Apache).

The question is, can JEE scale with the Long Tail? With internet access being nearly ubiquitous, websites will potentially have to handle hundreds of thousands of simultaneous transactions. Is JEE, a framework that’s great for the enterprise where there are a relatively small amount of simultaneous transactions, appropriate for coping with world-wide scale?

I hope so. But maybe lighter-weight, narrow-purposed scripting languages are more ideal.

Anyway, if you have experience with JEE dealing with “internet-sized” volumes, or if you know of any other JEE-based web 2.0 sites, please let me know.