Skip to content


Enterprise Rails: Why I Can’t Use Rails in My Enterprise

Unlike this guy, I’m going to actually articulate some roadblocks to running Ruby on Rails in an enterprise environment. I tried to implement a couple of real world applications I wrote (using Java) in my day job using RoR. I’ve been playing with Ruby on Rails off and on for over a year now, and finally felt comfortable enough to try solve some of the programming problems I encounter. Here’s what I found:

1. Web Services
If you are connecting to a simple web service, and just passing around a few primitives, ActionWebService is a dream. It’s everything you could hope for in connecting to a web service. Well, maybe something to generate the API would be nice, but even that’s not very painful, for a simple service it might take you, what, 30 seconds to code the API? But that’s the rub, a simple web service is drop dead simple, a complex web service is, for all practical intents and purposes, impossible. One web service that virtually every application I develop has to connect to has about 12 complex types, nested of course, and a layer of abstraction. AWS is way short of the mark, and soap4r, well it’s not any better.

2. Databases
In my, albeit, limited RoR experience, connecting to a database (MySQL is arguable) is a huge let down. First, just getting connected to the database is jolly trip down Painful Lane. I’m all for not duplicating effort, so it makes sense, on the surface, to use the existing client, and just wrap it in Ruby. However, in my mind, you end up sacrificing portability, because now that’s one more thing I have to have installed on the system I want to deploy my application. It pains me a little to say it, but this in one place where I think Java has the upper hand, just drop a jar file in your classpath and go. After all, this really is Java’s claim to fame: you could get connected and use a database quicker and easier in Java, than any other language. To unseat Java, Ruby needs to make the process of getting connected to a database simpler.

But easing connection woes is not the whole story, performance is other half. I watched somebody struggle for a long time getting a Ruby script to connect to an Oracle database, only to have it be outperformed by Perl by a huge margin.

3. Transactions
I’ve looked at [Transaction::Simple|http://railsmanual.com/module/Transaction::Simple], but it just isn’t complete enough for *my real world* needs.

4. Encryption
Encryption is really is the deal breaker. I can find ways to work around, and work through the other three issues, but I’m not about to try and implement an encryption algorithm. If you need, an encryption algorithm that uses CBC, you might be able to get the job done. I however needed, oh I don’t know, AES/Rijndael using ECB, well, you’re out of luck (unless you’re using Windows then you can use Chilkat, but who wants to do that?!?).

The good thing is I don’t think any of these are hurdles that RoR can’t overcome; it’s a question of when, not if. Now I can sleep at night knowing that I tried RoR. I will keep my eye on it, and as soon as these issues are resolved, I will re-evaluate making the leap.

Posted in Ruby, Software Development.


One Response

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

Continuing the Discussion

  1. Jtanium’s Blog » Blog Archive » Enterprise Ruby on Rails: Update linked to this post on March 6, 2007

    […] Fortunately for me, nobody actually reads this blog. Oddly enough I’ve spent more (much more) time working with Ruby. It turns out that I may have been being overly harsh in my post Enterprise Rails: Why I Canat Use Rails in My Enterprise; Ruby, and Rails, is quite adept at web services and transactions. […]



Some HTML is OK

or, reply to this post via trackback.