| Ruby on Rails to Nowhere |
|
A long time ago, I was on a NOLS adventure in the middle of the Olympic mountains. My group was resting one day high above the tree-line in a snow covered area when we found a small, but steep bank of snow ... perfect for headfirst nosedives. It all seemed harmless at the time, until our guide angrily reminded us that whatever choices we make, the fact remains, we must weigh the risk versus the reward. Shocked at first by his reaction, we all suddenly had the realization that given our surroundings and circumstances, the risk we were taking was much greater than the reward. This article about Twitter recently reiterated to me some real risks with Ruby on Rails. Whether or not Twitter is abandoning Ruby on Rails, the risk of a severely flawed framework remains. Ruby on Rails is a language and platform that makes web application development quicker and more maintainable. One of its strength is that the Rails Framework enforces consistency in style and encourages code reuse. Past that, Ruby as a language is just another language. Rails is an innovative framework, but it is only a framework. Many arguments are made regarding the technicalities of Ruby and other languages. I do not wish to rehash these arguments; but instead, I make an assertion that by choosing the Ruby on Rails platform in an "Enterprise" environment, your organization is taking unnecessary risks considering its surroundings. For the last two years or so I noticed a new wave of energy surrounding Ruby on Rails. I encountered some very strong proponents of Ruby on Rails who wanted to use it in an Enterprise setting -- I always had one simple concern: Ruby on Rails is a two tiered platform; thus, fundamentally flawed. A Ruby on Rails application is doomed to scalability issues. So while it may be fun implementing a web application using a new innovative platform, it will not be fun when your company is finally on the verge of success only to discover it has a severely under-performing application on a platform that provides few options to scale. Twitter anyone? Now, consider the recent support that companies such as IBM have put behind a long time leading web application language, PHP. By leveraging PHP, a developer can now overcome many of the "ease-of-development" drawbacks of developing a traditional multi-tiered Java based web application, but still have the facilities of a highly scalable application server environment such as WebSphere XD. Much like sledding down a hill, creating a simple web application using Ruby on Rails has its advantages. However, when you consider the surroundings of an Enterprise Environment, it is hard to consider any situation that Rails is worth the risk. Comments (4)
  written by craig, May 14, 2008
What makes you believe RoR is any different than PHP with regard to 2-Tier v. n-Tier? And what leads you to believe RoR is 2-Tier?
report abuse
vote down
vote up
Votes: +3
 written by Mark Murphy, May 14, 2008
Since I was working on 2-tier/N-tier applications back when you were probably still learning how to spell, allow me to explain.
Tiers, in the context of 2-tier/N-tier, refer to disparate computers participating in the user's application experience. Tiers refer to where application code executes; things like routers and load-balancers don't count, but databases (containing application-specific tables, stored procedures, etc.) do. And, a single tier can contain multiple PCs, if they're all serving the same purpose (e.g., all clients are on one tier; a load-balanced set of database servers is one tier). Hence, a 1-tier application is something that runs completely on one PC. The basic version of Quicken, for example, has its data file on the PC and has its user interface on the same PC. A 2-tier application has a split, typically between where the user interface runs and where the rest of the application logic runs. The old "client-server" model is 2-tier, where you have a fat client talking straight to a database, such as QuickBooks Enterprise. A Web application can be 2-tier, if and only if there is no database server, transaction server, or anything beyond the process (or load-balanced set of processes) that is the Web application itself. So, PHP, RoR, and Java can all be 2-tier, if they use embedded databases like SQLite and Apache Derby. The two tiers, therefore, are the client (Web browser/RIA) and Web application. A 3-tier application, nowadays, typically is a client tier (e.g., Web browser/RIA), a Web application tier (PHP, RoR, Java), and a database server tier (MySQL, Oracle, PostgreSQL). Saying "Ruby on Rails is a two tiered platform; thus, fundamentally flawed" is hogwash. RoR can use three tiers, and a 3-tier model is what the RoR developers have recommended (SQLite relegated to development/test purposes). Similarly, PHP, Java, or any other Web application technology you can name can be used as "a two tiered platform; thus, fundamentally flawed", though frequently they are used with three or more tiers. If you need more tiers, RoR and Java (and maybe PHP) can use reliable messaging frameworks like ActiveMQ to offload processing to other application servers. There is nothing magic about Java or PHP that make them automagically scalable and RoR not. In the wrong hands, any of those technologies can create non-scalable applications. If you're going to create a Twitter-sized application, you better have Twitter-capable engineers, no matter whether you implement in RoR, Java, PHP, or raw machine code. Note that I'm personally not a big fan of RoR, but scalability isn't the concern. report abuse
vote down
vote up
Votes: +5
 written by Randal L. Schwartz, May 14, 2008
For a truly scaling solution in this arena, consider Seaside (http://seaside.st), which when running on GemStone/S, can scale far beyond what Twitter would have needed. Or even running on Cincom VW, with commercially supported GLORP and ActiveRecord talking to SQL-based databases.
report abuse
vote down
vote up
Votes: +1
Write comment
|
Subscribe to this comment's feed
http://www.ibm.com/developerwo...ngton.html