Bringing Rails to the Enterprise

by Tim O'Brien

(correction): fixed Upton Sinclair quote it is 'salary' not 'job' (thanks for the correction)



Even with all the buzz, it is still a tough sell. If you've suggested Rails as an alternative to (Java|.NET) at work, you've probably experienced some reactionary pushback. Convincing a set of established "Enterprisy" engineers that Rails is worth paying attention to it is like convincing a Texas oil baron that he should purchase a Subcompact hybrid vehicle and become a Vegan. Why is convincing a highly paid (Java|.NET) programmer to look at Rails that difficult? I'll steal a quote from Al Gore's Inconvenient Truth that he, in turn, stole from Upton Sinclair:

"It is difficult to get a man to understand something when his salary depends on not understanding it." - Upton Sinclair (1878 - 1968)

In an effort to convince, you may have sent people to some of the good Ruby on Rails blogs. This might have escalated the resistance. Asking your fellow enterprise developers to read DHH's loudthinking.com, is like asking (the other) O'Reilly to sit down with Colbert - Mr. Enterprise isn't going to appreciate the message because he'll be focused on the ridicule. Rails, rightly so, is positioned as the challenger, and it makes good use of hyperbolic ridicule to gain converts. This works for most of us, but I've also seen it push some entrenched Java developers further away.

Common Responses

So, you are in "The Big Planning" meeting, and your boss says something like, "There is no time to finish this project, we're going to have to tell the customer we won't meet the deadline." You wearily offer up the suggestion: "We might be able to deliver something on time if we used Rails to implement the web application". And, an entire room full of Java programmers is now trying to tell you every reason from here to the North Pole why your suggestion is naïve. Here are some of the common responses:

  1. Freedom (Too Much) - "Our developers are not disciplined enough to use a scripting language."
  2. Rigor / Formality - "Our systems are serious and require a much more rigorous approach."
  3. Performance - Our systems need to perform, and Ruby (specifically Ruby on Rails) doesn't perform to our standards.
  4. Flexibility (Not Enough) - (Rails) We can't afford to follow the database standards that Rails would impose on us

Let's take each one individually...read on...


27 Comments

bryanl
2007-01-19 11:40:55
This article was titled, "Bringing Rails to the Enterprise," and it missed one important thing that Rails isn't very good at yet: Integration with other Enterprisey Applications. We are making headway with plugins like activemessaging, but with the stifled soap4r development, and the amount of research it would take to actually have your .NET or or Spring/Tapestry/Hibernate application integrate with your Rails app could be overwhelming to the "undiciplined masses"


Keep in mind, that I have great hopes for Rails, and that is why all my applications are based on Ruby and or Rails at the current second. Rails is on its way, but hasn't quite arrived to its rightful place in the Enterprise.

Tim O'Brien
2007-01-19 12:04:22
@bryan,


Rails is a full stack (web 2 db), it tends to reach down into the database, and for most of what I do, this is where the real integration happens. A rails app will modify the same database a SOA framework written in Java uses, then my rails app might notify some workflow engine (something in BPEL) that data is ready for action.


but, i think you are right, you still have to be creative when it comes to integration with a larger existing framework.


soap4r is pretty capable from what i've seen so far, tell me what the challenge has been? For most of the stuff I've been doing I'm usually stepping back to XML and using REXML to parse messages produced by existing Java systems.


One promising messaging opion is to use STOMP, I know ActiveMQ uses it.

Mark Haliday
2007-01-19 12:08:11
"Rails isn't very good at yet: Integration with other Enterprisey Applications."


I've gotten Rails and .NET talking very well together. Took about 15 minutes of troubleshooting and bang it was going via SOAP. Passing complex objects was also very easily done.


One argument I bet others hear:


"We are an IIS shop, Rails doesn't run on IIS very well other than a hack, nor does it run as well on Windows as it does on OS X or Linux".

Justin
2007-01-19 12:32:15
One thing that blocks Ruby adoption in the Microsoft-oriented shops is that you can't use the gem command if an authenticating proxy (i.e. ISA Server) is in the way. I created a gem to solve this problem, for Windows clients at least. It allows Ruby to authenticate with the proxy server as the current user, just like IE and Firefox, without requiring you to type a password or username anywhere.


The gem can be installed via 'gem install rubysspi'. The ruby forge project page is at


http://rubyforge.org/projects/rubysspi/


InfoQ did a write up on the gem which explains its benefits nicely:


http://www.infoq.com/news/2006/11/rubysspi-gem-released

bryanl
2007-01-19 12:35:11
I've gotten Rails and .NET talking very well together. Took about 15 minutes of troubleshooting and bang it was going via SOAP. Passing complex objects was also very easily done.


I'm not saying this isn't possible. I have a Rails app that talks to Axis and .NET based servers. It also passes messages using the STOMP protocol by way of the ruby stompserver.


Can Rails interact with JMS with minimal configuration? Yes, but you will need an extra plugin and a server like ActiveMQ to translate STOMP to JMS


Can Rails access SOAP based APIs? Yes, but you will need to make sure you have a current soap4r installed, and you may run into configuration issues if you have http-access2 installed.


To really bring Rails to the Enterprise, functions like I mentioned before need to be *easy* to do. I don't know whether this means including more functionality into Rails (i really hope this won't happen), or does it mean that there needs to be better documetation on how make Rails interact with other Enterprisey apps. I do know that Rails will have to be *easier* to use because unlike Java and .NET, Rails doesn't have huge corporate backers with extremely large advertising budgets. So for Rails to actually exceed in those environments, it really will have to be easier to use and better performing with minimal configuration.

Corporate Guy
2007-01-19 14:09:35
I still think Rails isn't a serious option for most of us. Your article doesn't address the cost of retraining a whole department to support rails. Thanks for wasting my time.
Tim O'Brien
2007-01-19 14:12:24
@Corporate Guy,


*Shrug* OK, well I guess you are never going to use new technology or try anything that requires people to adapt to changing technology. So, Mr. Corporate Guy, let me get this straight, your argument against Rails is "My people can't learn anything new."


David Pollak
2007-01-19 15:53:51

While it's true that for low volume sites, Rails is fast enough, it's not true that it scales the same way Java does. Because you have to have a 40MB mongrel instance for each simultaneous request, you wind up using much more memory and hardware for medium to large volume Rails apps than Java apps.


Scaling teams with duck-typed languages is much harder than scaling teams with statically typed languages. This is doubly difficult when the team is used to the compiler being one of the tests that they run (does it compile?) The switching costs to get a team of Java or C# developers to really test-first and stop relying on the compiler is a 6+ month task. During that time, you lose a lot of the development speed issues that you gain with Rails.


A language without interfaces makes defining the responsibilities of different groups that much harder. Java development can scale to many teams of 10+ people. I have not seen a Rails project with more than 2 teams and more than 10 people total. Yes, some of this is because of Java's overhead (you need people) but sometimes the projects get more complex than can be handled by the small, agile team.


An important part of any web application is deployment. Most enterprises have QA and ops teams that know how to do Java. Changing the platform means changing what the developers, the QA and the ops teams do. This is a broader change than "you three guys go prototype this in Rails and if it looks good, we'll deploy it." The QA folks are expecting WAR files. The ops guys are expecting WAR files. Rails means Ruby and gems and rails and a c/c++ compiler and mongrel on *every* machine in the process from developer to deployment. This is a huge and costly burden and can often eclipse the cost of developing 1 or 2 apps 30% faster.


Finally, Rails does certain things very, very well. However, Rails is very weak in other areas. Writing multi-page "wizards" is easier in Java with Struts than it is in Rails. Managing complex state that does not directly map to tables in the database is more difficult in Rails than in J2EE.


For simple CRUD apps that can be written by a small team and deployed on an "off-grid" (e.g., intranet departmental server), Rails is a much better choice than Java. For big, hardcore apps, Java is a better choice.


So, for everyone who's about to flame me, "Yes, I use Rails." 70% of the lines of code I write are Ruby and they're evenly split between Ruby applications and Rails apps. I also write in Java and most recently, Scala. I've got 8 Rails apps currently in deployment (6 are commercial.) I've been doing Rails for 18 months and Java for 10 years. For small projects, I recommend Rails. There is *not* a linear relationship between a small Rails project and an enterprise project.



Tim O'Brien
2007-01-19 17:58:57
@David P.


First, thanks for the awesome response. I've got some disagreements no doubt, but for you to take the time to respond shows that this is an interesting debate, and your response is going to add clarity for anyone looking at the alternatives.


Point by point:


"While it's true that for low volume sites, Rails is fast enough, it's not true that it scales the same way Java does. Because you have to have a 40MB mongrel instance for each simultaneous request, you wind up using much more memory and hardware for medium to large volume Rails apps than Java apps."


Again, this really depends on the specific situation. First, we're talking about, in real terms, scaleability or simultaneous user capacity. So, let's take the basecamp figures stated by DHH from here. He says ~500k requests with 2.5 servers in late 2005, I'm going to assume this has increased. I've worked on sites that have at least 10-20 times that traffic level, and at a site like that you usually end up spending a truly inordinate amount of cash (a million) on servers. At the client that had this much traffic, during a spike, you would see about 600-800 request/sec. Not all of them required an application server, but you are talking about spreading load over tens of low-end servers (6x 2-way 4GB RAM) or a handful or super monster servers (2x 16-way 20 GB servers). A huge site has already spent millions on hardware, and using your metric of 40MB per instance, you would need approximately 24 GB to serve 600 simultaneous dynamic requests via a bunch of Mongrel boxes. That's not too different from what you would need to host a comparable Java application.


David, for the site that really needs to scale. I'm going to bet you a million dollars that RoR isn't going to be the first thing to fall on the floor. First, you'll be optimizing content delivery way before your site has to handle 600 req/sec. You'll be making some pages static, and the more likely pain point is going to be the database. If anything is going to be a limit it is going to be MySQL, and that's independent of your choice of framework. For the largest sites on the Internet, the difference in cost is going to be imperceptable.


For medium sites, we're still not talking about an unrealistic scalability scenario. Let's take a site that could expect 2 million hits spread equally throughout an eight hour working day. This translates to about 70 req/sec. This is no small site, but even then, by your estimate of 40MB per instance, we're only talking about 3 GB of RAM. Now you might say, 2 million hits won't be spread out evenly over an entire day, I'll have spikes of 3x average traffic. Even at 200 req/sec, we're only talking about 8 GB, and if your site is getting 2 million hits a day (and under the unlikely circumstance that every request is dynamic), I'm sure your organization would prefer to pay for the RAM vs. the developers. At 8 GB, we're talking two serious low-end servers with 6 GB a piece or maybe 4 commodity boxes.


Scaling teams with duck-typed languages is much harder than scaling teams with statically typed languages. This is doubly difficult when the team is used to the compiler being one of the tests that they run (does it compile?) The switching costs to get a team of Java or C# developers to really test-first and stop relying on the compiler is a 6+ month task. During that time, you lose a lot of the development speed issues that you gain with Rails.


So, I can't argue with this. I think that if your team isn't unit testing already, you are probably going to have problems regardless of the platform. I use Eclipse for Java development, so the compiler helps me while I'm writing code, but the real bugs in programming can't be solved by a compiler. I guess my response to this is, I'm not advocating the 50,000 line analog to a Java program. It's not the same language. And, no one's advocating that you abandon your current platform.



A language without interfaces makes defining the responsibilities of different groups that much harder. Java development can scale to many teams of 10+ people. I have not seen a Rails project with more than 2 teams and more than 10 people total. Yes, some of this is because of Java's overhead (you need people) but sometimes the projects get more complex than can be handled by the small, agile team.


I have seem projects that scale to teams of independent developers, take a look at Ruby Forge, and imagine that each gem you install has a team of 10+ ruby developers. This argument is less about the technology and more about the packaging. Just like I might split up a Java effort across a set of separate projects and functional teams using something like Maven to manage the interdependencies and build process, I could do the same with a Ruby project and gems.


An important part of any web application is deployment. Most enterprises have QA and ops teams that know how to do Java. Changing the platform means changing what the developers, the QA and the ops teams do. This is a broader change than "you three guys go prototype this in Rails and if it looks good, we'll deploy it." The QA folks are expecting WAR files. The ops guys are expecting WAR files. Rails means Ruby and gems and rails and a c/c++ compiler and mongrel on *every* machine in the process from developer to deployment. This is a huge and costly burden and can often eclipse the cost of developing 1 or 2 apps 30% faster.


Social argument. By this logic you'll never move away from your current platform. Sorry guys, we can't use anything other than Java because the QA team only knows how to test Java. While both groups may specialize in push back, I think you'll find that both groups will welcome the change. For the QA team - if they are doing functional tests then the platform shouldn't make much difference. If you are working for a real enterprise, chances are good that you already have more than one platform to test, and if the QA is doing a good job, they have tools that can test applications at the protocol level and mimic the browser. Your ops team will probably fall down on the floor and thank you. Once you show them tools like Capistrano, you might even hear them asking why Java deployments can't be this easy.


Seriously, ever set up Tomcat and mod_jk? Or how about the false promise of hotdeploying a WAR (it rarely works because of screwy ClassLoader issues). Using Capistrano, we're literally talking about "deploy" and everything is automated remotely.


Finally, Rails does certain things very, very well. However, Rails is very weak in other areas. Writing multi-page "wizards" is easier in Java with Struts than it is in Rails. Managing complex state that does not directly map to tables in the database is more difficult in Rails than in J2EE.


Depends on the experience. Yeah, I think that hyper-AJAX is a little easier on Wicket, and if I were a Microsoft programmer, I'd probably say something similar about Atlas. But, I've seen plenty of people create wizards in Rails with less effort than it takes in Struts. Don't get me started on Struts, just go read my previous posts on OnJava.


For simple CRUD apps that can be written by a small team and deployed on an "off-grid" (e.g., intranet departmental server), Rails is a much better choice than Java. For big, hardcore apps, Java is a better choice.


Not so fast. I would have to agree that if you are building the mega-super-complex-enterprisy system, you probably don't want to use Rails. That's not what it's made for anyway.


So, for everyone who's about to flame me, "Yes, I use Rails."


Don't flame David, he's half right and I'm half wrong.

Brian G.
2007-01-20 02:20:31
@ David P


"However, Rails is very weak in other areas. Writing multi-page "wizards" is easier in Java with Struts than it is in Rails."


Take a look at http://evang.eli.st/blog/2007/1/12/declarative-workflow-in-rails. I think you'll have a hard time doing the same thing more easily in Struts.

Ron Evans
2007-01-20 09:14:24
Gentlemen, this discussion is fantastic. I have been dealing with many of these same issues, and this conversation has given me a lot of new ideas to throw into the mix to get Ruby and also hopefully RoR accepted by my corporate masters.
Just to get back to a couple of points made in some of these comments, but not yet addressed by the group:
- What about the IIS deployment/Windows platform deployment issues
- What well as the soap4r performance problems (REXML really being to blame here)?
And has anyone mentioned the SQL Server integration challenges yet?
Greg
2007-01-20 10:26:17
@Brian


Very nice declarative work flow example!

Yeah Right
2007-01-20 13:02:46
You can't answer to one myth with another. Your assumption, or perhaps implication, about performance is that .NET is faster than Java...which is dead wrong. You can't conclusively prove that the latest Java or .NET runtimes and containers are faster than the other. But I'd bet you that I could prove to you without a doubt that Java AND .NET are both faster than Ruby on Rails. So how about it? Are you willing to put your money where your mouth is?
Sheesh
2007-01-20 13:06:04
Reading through this a second time, I don't think you know anything about how to build Java or .NET applications if you believe any of this yourself. Ruby on Rails allows you to challenge current thinking, like doing what makes sense rather than what the textbooks say. Why are you afraid to challenge standard practices without changing the platform?
Tim O'Brien
2007-01-20 14:53:31
@Yeah Right,


The "speed" issue is never about execution time, and it is always about scaleability. If baseline "execution time" were the measure that mattered we wouldn't be using .NET or Java for anything, we'd still be using C. I'm willing to put my money on the line and say, you can create a Rails site that scales for an investent comparable to what organizations pay to scale large enterprise Java or .NET systems.


Your discussion of the differences between .NET and Java don't make sense. I'm not making any comparison between the two.


Now can .NET and Java run quicksort more efficiently and quicker than Rails, sure. That's not my argument, my argument is that request time is rarely the issue - the issue is always scaleability AND the gating factor is never the server technology used, it is mostly the database. Furthermore, when companies get serious about scaleability that usually find a way to offload requests to static resources.


Tim O'Brien
2007-01-20 14:58:06
@Sheesh,


"Reading through this a second time, I don't think you know anything about how to build Java or .NET applications if you believe any of this yourself. Ruby on Rails allows you to challenge current thinking, like doing what makes sense rather than what the textbooks say. Why are you afraid to challenge standard practices without changing the platform?"


OK, so this is the "Why change platforms, we could just do the same thing in Java" argument. I'm not sure I follow this one, first, unless you intend to get into the framework invention business, there is nothing comparable to Rails in either .NET or Java. There are wannabes like Grails that are derivative (and badly so). Then there are true contenders like Rife which need more time if they are going to compete (and did I mention they don't have the community).


but, I don't follow the argument, especially the anti-intellectual appeal to Rails as an anti-textbook technology. What? Ruby is a programming language.


Nick Snels
2007-01-21 05:34:22
This discussion is more about opinions than about hard facts. If you are using a programming language or a particular framework and you are happy with it or have already invested a whole lot of time or money into it, there is no need to make the switch. Java, .NET, Ruby they are all great languages.


Ruby on Rails shines in rapid web development and integration of all the things you need when developing a web page. If you need to develop more complex task Java and .NET are probably more suitable. But for many projects Java and .NET can be too complex, if you don't have experienced developers. I'm glad I made the swith from PHP to Ruby on Rails, it has made my life a lot easier. I like Java and I'm also currently using it alongside Rails on my site http://www.railshostinginfo.com and they work nicely together. So it is just a matter of finding the right tools for the job.

Paul
2007-01-22 08:04:59
Rails seems built for simple gui generation on top of services built in .NET or Java. As for the crud generation aspect, a zillion frameworks do that now, and some of those even include Ajax-y functions, so Rails 5 minutes are almost over.


It *does* matter that Ruby is slow. It is not a good general programming language. It's best at very small, very simple operations, and then speed doesn't matter.

Tim O'Brien
2007-01-22 08:11:13
@Nick,


Yes, this is opinon, that's why the post is categorized as opinion, and I'm glad you shared yours because it is one I'm in agreement with. I advocate a mixed approach - use Rails where it works, and use Java (or .NET) when you need to. This blog entry is more targetted at the organization that religiously clutches to a single platform.

Tim O'Brien
2007-01-22 08:16:20
> It *does* matter that Ruby is slow. It is not a good general
> programming language. It's best at very small, very simple
> operations, and then speed doesn't matter.


Funny, did you read the entry? Am I advocating that your Enterprise move everything to Rails? No.


I'm also pretty much convinced that anyone who says that "Ruby is not a good general programming language", probably hasn't given it a chance. As a language it seems much more capable than most, and just like Java hurried to play catch up with C#, we're seeing Java hurry to catch up with dynamic languages in general.


And, I know about other languages that received a similar reception. Among them - Java. Java was once considered a "slow language", and for the first few years it existed, people would scoff at the notion that Java could handle anything serious. IMO, the speed issue will be addressed (and I'm hoping that the speed issue is addressed when Ruby and Rucy on Rails runs in the JVM)


So when does a technology become serious enough?


Tom Copeland
2007-01-23 03:13:11
> The QA folks are expecting WAR files. The ops guys are expecting WAR files.


That's a bit of a "tail wagging the dog" situation. Auto parts stores stock billions of today's parts, and car repair shops have lots of people who know how to fix today's cars. But Ford keeps coming out with new models year after year, and somehow the parts people and the repair people adapt. Surely we can expect the same from our QA and ops folks.

twr
2007-01-26 12:43:08
It would be interesting if anyone who is a current or former engineer at Revolution Health (http://www.revolutionhealth.com/) would comment. That's the only large, high-profile site built almost entirely in Ruby on Rails.
albert bulawa
2007-02-08 14:10:15
How do I cluster Rails? How does Rails scale to thousands (or tens of) of requests a second?


The answer: use Java.

Luke
2007-03-24 16:50:28
Every major language has had the problems that are facing Ruby and Rails right now: when they first come out, they have to fight for every single inch of respect. The entire web development world is shaking right now as we strive (and are coming very close to attaining) to make using a service on the web just like using one installed on the PC, and there are a ton of frameworks/languages trying to come out as THE language that you should obviously use when developing.


I don't think that's ever going to happen. I think what will happen is the frameworks and languages will become ever closer to each other in both capabilities and speed. And beyond that, as is happening now with JRuby, you will be able to use both languages in the same context, to talk back and forth to each other. Everyone's happy! You can tie Rails onto the back of Java, use native threads, use whatever you need... they both work, and you get the best of both worlds.


The mingling of languages is what's really going to take off here soon... when you don't have to have only Java developers, or only Ruby developers on your team: you just specify certain methods of interaction required of any modules developed by either team, and they will be able to natively call each other's code.


Just imagine... all the development speed advantages of using Ruby, but with the underlying backing of things like Hibernate, etc. What won't we be able to accomplish then?

Jake
2007-05-11 13:30:54
Umm, I think you missed some of the key requirements of a technology being deemed "enterprise" worthy... It has nothing to do with how fast I can get a simple screen interacting with a simple database. I can do the same thing in php.


"Enterprise" requirements revolve around security via various means of authentication / authorization as well as fine-grained ACLs and roles, distributed transaction management, EAI with legacy systems like CICS, messaging, etc... I can continue if you'd like...


An "enterprise" app isn't just about getting a screen to the user.


Rails has no answer in the enterprise space. Your arguments above aren't even mentioned when it comes to deciding on an enterprise platform...

Tim O'Brien
2007-05-11 13:46:06
@Jake, sure, alright, I'll make sure to tell that to the large enterprises that I know of who have already started to integrate Rails into enterprise systems.
roger pack
2007-06-08 14:15:06
It "seems" that rails does scale, if you chuck enough servers at it. As I state on my blog it would be nice to have a 'scale off' in terms of 'how many things you can serve with 5 machines using each language' or what not. That would be very interesting :) Let the best of each camp... http://betterlogic.com/roger/?p=58