Despite what Joel has to say on this topic, I think Rails is ready for the enterprise. And companies who create enterprise apps should definitely be looking at Rails. Here’s why…
Having worked with PeopleSoft for over ten years, I’ve had the pleasure to experience the joy in building enterprise applications with a rapid and productive environment called PeopleTools. Although PeopleTools is now out-dated in comparison to more modern frameworks, it was (and still is) the most productive development framework I’ve ever worked with (i.e., for building enterprise applications).
Over the past several years, I’ve kept myself up-to-date with new programming languages, frameworks, and platforms and have seen lots of innovation in different areas. Some of it has been relevant to the enterprise, and some not. In the last decade, much of what’s influenced the enterprise software industry are ideas and products that have been successful on the web. PeopleSoft and its peers ported their client-server apps to the web because of the value it posed to its customers — cheaper and easier deployment of software. Today, the web continues to be the most disruptive influence on the enterprise.
The enterprise, however, is a very rigid landscape. Not much changes in this landscape unless it’s absolutely beneficial to the organization’s bottom-line. Today (and throughout the past decade), Java, XML, WS-*, SOA, and other ambiguous acronyms have been touted as the gold standard in the enterprise. An entire industry spins its wheels around this gold standard trying to make the promises of improving efficiency and productivity a reality. In my opinion, this gold standard is in need of change.
It might seem like I’m late to the party, but I’ve actually been tinkering with Rails since it’s 1.0 release, but as with any new emerging technology, you have to let it ferment a bit to see if it still smells pretty… especially when thinking of how it might affect the enterprise. Things move slow in the enterprise and there’s lots of red tape everywhere to make sure that the gears rotate at a slow clip. Most decisions are made by committee and if one party disagrees, it’s a show-stopper. So, getting Rails in the enterprise is not an easy thing to do. But you’re probably wondering why I think Rails is such a big deal for enterprise apps — at least for people who have to write enterprise apps. I’m not going to write about why Rails is an important technology. It’s been done, over, and over. What’s important to know is what Ruby is up against — the gold standard, Java. There’s been lots of feuds between the Java and Rails camps over the past few years and most of it is childish. It is obvious though that Rails struck a chord for many Java developers. Some have decided to join the Ruby camp, and some have held out thinking that this is just another fad. Well, I don’t think it’s a fad. Here’s my reasoning:
- Ruby on Rails is a super-productive environment for developing applications. It’s faster to build apps in Rails than in Java or .Net, hands down.
- Ruby is a powerful, easy to learn, fully object oriented language. Rails is nothing without Ruby.
- All the performance issues that Twitter (most popular Rails app known to man) is/was facing is not really relevant for enterprise apps. Point me to one enterprise application deployment needing to perform 11k requests per
minutesecond. Per Tim Bray, “Right now, Ruby and Rails, out of the box with not much tinkering, are plenty fast enough for lots of applications. I mean, really a lot of applications” - JRuby. Java is not going to fade away. It is and will continue to be an integral part of the enterprise. JRuby allows Rails to fit into that environment and leverage the hell out of it.
- Ruby’s community is growing by leaps and bounds every day… and so are its gems (libraries), plugins, etc.
I’ve built many applications with PeopleTools, which has many similarities to Rails (with regards to productivity for developers). It’s still a good framework for building applications (arguably the best in its class), but it is behind the times. I see Rails as the next logical step in the enterprise apps business. Although, this might just be wishful thinking on my part.
For many years I have been managing plenty of Oracle E-Business Suite implementation projects for our customers. And recently I have been studying Ruby on Rails and I am really enjoying it.
So I can compare current PL/SQL and Java technologies in EBS vs RoR and I see that RoR really would be much more productive environment for building enterprise applications.
But so far as I have seen Oracle is building new Fusion applications just on Java technologies and currently I do not see that Oracle is considering using more productive dynamic languages for that.
Do you have any “inside” information if Oracle is considering Ruby or some other dynamic languages for their Fusion applications platform (or at least some part of it)?
For many years I have been managing plenty of Oracle E-Business Suite implementation projects for our customers. And recently I have been studying Ruby on Rails and I am really enjoying it.
So I can compare current PL/SQL and Java technologies in EBS vs RoR and I see that RoR really would be much more productive environment for building enterprise applications.
But so far as I have seen Oracle is building new Fusion applications just on Java technologies and currently I do not see that Oracle is considering using more productive dynamic languages for that.
Do you have any “inside” information if Oracle is considering Ruby or some other dynamic languages for their Fusion applications platform (or at least some part of it)?
Rich,
Thank you for a great article. I agree with a lot of what you say, and believe too that language wars are pointless. At ADS, we are looking a lot into JRuby, and I have posted a tutorial on the ADS blog as well. I look forward to deeper language integration and the spread of Rails into the enterprise.
– Robert Dempsey
Rich,
Thank you for a great article. I agree with a lot of what you say, and believe too that language wars are pointless. At ADS, we are looking a lot into JRuby, and I have posted a tutorial on the ADS blog as well. I look forward to deeper language integration and the spread of Rails into the enterprise.
– Robert Dempsey
It’s far easier to create such a productive suite such as PeopleTools / PeopleSoft did when you control the whole stack! Comparing it to building an enterprise web application, utilizing at least 5 different technologies(html, css, javascript, xml, json) for the front end alone is comparing apples to elephants.
Not that everyone is successful! Peoplesoft did a good job. But w/ them building everything down the a proprietary language…all the elements are in place!
I agree, Rails has its place and I can think of a number of places it can be used for corporate internal apps. But would I use it to build the high profile, mission critical app avail 24×7 worldwide? No…
I’ve done rails, django, and java enterprise for a long time. IMHO, if you are building a crud app, it’s very fast to do the same in java, esp if you leverage a stack like appfuse, or use hibernate / ibatis to generate your persistence layer. most of the dev time is spent in the UI’s
It’s far easier to create such a productive suite such as PeopleTools / PeopleSoft did when you control the whole stack! Comparing it to building an enterprise web application, utilizing at least 5 different technologies(html, css, javascript, xml, json) for the front end alone is comparing apples to elephants.
Not that everyone is successful! Peoplesoft did a good job. But w/ them building everything down the a proprietary language…all the elements are in place!
I agree, Rails has its place and I can think of a number of places it can be used for corporate internal apps. But would I use it to build the high profile, mission critical app avail 24×7 worldwide? No…
I’ve done rails, django, and java enterprise for a long time. IMHO, if you are building a crud app, it’s very fast to do the same in java, esp if you leverage a stack like appfuse, or use hibernate / ibatis to generate your persistence layer. most of the dev time is spent in the UI’s
Arguing RoR is ready for Enterprise Apps you have to define an enterprise app!
1) Ruby on Rails is a super-productive environment for developing applications. It’s faster to build apps in Rails than in Java or .Net, hands down.
Well – Rails is a web-app tool, comparing it to Java or .Net is like comparing apples and oranges. You should be comparing RoR and JSF, Tapestry, Ripes (insert your favorite Java or .Net web framework here).
2) Agree.. totally
3) Again – you have to define enterprise app. I can easily point you to an enterprise app which should/and is capable of handling MORE than 11k request pr. minute (think corporate back-bone CICS like systems and you’ll see WAY more requests)
4) Yes – Rails of JRuby will help the Rails fw to spread. Its the JVM platform that is really interessting.
5) Sure (I dont know – don’t follow Ruby nor Rails much)
Still – Not being much of a Rails kinda guy can you easily write and deploy remote (RPC style) entities with transactional contexts (2PC) and such in Rails.. Else I declare: NO CONTEST!
Arguing RoR is ready for Enterprise Apps you have to define an enterprise app!
1) Ruby on Rails is a super-productive environment for developing applications. It’s faster to build apps in Rails than in Java or .Net, hands down.
Well – Rails is a web-app tool, comparing it to Java or .Net is like comparing apples and oranges. You should be comparing RoR and JSF, Tapestry, Ripes (insert your favorite Java or .Net web framework here).
2) Agree.. totally
3) Again – you have to define enterprise app. I can easily point you to an enterprise app which should/and is capable of handling MORE than 11k request pr. minute (think corporate back-bone CICS like systems and you’ll see WAY more requests)
4) Yes – Rails of JRuby will help the Rails fw to spread. Its the JVM platform that is really interessting.
5) Sure (I dont know – don’t follow Ruby nor Rails much)
Still – Not being much of a Rails kinda guy can you easily write and deploy remote (RPC style) entities with transactional contexts (2PC) and such in Rails.. Else I declare: NO CONTEST!
The problem with development of great enterprise applications has very little to do with the speed at which the problem can be expressed in a language. Developer productivity is much more closely related to design and determining what to code. The actual act of coding could be as little as 20% of the total time during the SDLC.
The other consideration is scability and support. I’ve looked at Twitter and they don’t get 11K messages per minute – looks like more like 11K requests per hour.
The messages are pretty small. What if you get 4 million messages per hour and each message is 200K, not 140 characters as with Twitter. Or you need to support 15,000 simultaneous user sessions.
The hardware required is extreme, eBay has 2000 J2EE servers. If they were running Rails, I think they would need 4000+ servers. These things aren’t free and they cost for a long time.
If Ruby could be used to create features that simply could not exist in Java, then go for it. Just remember the time saved for a few developers is being offset in continuous server maintenance for twice as many servers. All for the convenience of a few hours of coding?
Think about it.
The problem with development of great enterprise applications has very little to do with the speed at which the problem can be expressed in a language. Developer productivity is much more closely related to design and determining what to code. The actual act of coding could be as little as 20% of the total time during the SDLC.
The other consideration is scability and support. I’ve looked at Twitter and they don’t get 11K messages per minute – looks like more like 11K requests per hour.
The messages are pretty small. What if you get 4 million messages per hour and each message is 200K, not 140 characters as with Twitter. Or you need to support 15,000 simultaneous user sessions.
The hardware required is extreme, eBay has 2000 J2EE servers. If they were running Rails, I think they would need 4000+ servers. These things aren’t free and they cost for a long time.
If Ruby could be used to create features that simply could not exist in Java, then go for it. Just remember the time saved for a few developers is being offset in continuous server maintenance for twice as many servers. All for the convenience of a few hours of coding?
Think about it.
I think you missed the point of what Joel was saying. He basically said that until Rails has been used for a few more years nobody is going to really know if Rails is mature enough to go enterprise.
Point 3. I think you underestimate the number of hits that some ‘enterprise’ services cope with.
E.g.
Sainsburys (or any other big supermarket online system)
bt.com (mainly run on weblogic, but mostly customer facing)
I think you will find both of these easily have to cope with 11k+ per min.
And I cannot possibly imagine either of these companies taking a gamble on building using Rails. And Joel was just showing that he thinks with his business head first, putting risk before ‘whats hot’.
I like Rails & Ruby but for enterprise it is not proven compared with (C#, Java, PHP, or Python).
I think you missed the point of what Joel was saying. He basically said that until Rails has been used for a few more years nobody is going to really know if Rails is mature enough to go enterprise.
Point 3. I think you underestimate the number of hits that some ‘enterprise’ services cope with.
E.g.
Sainsburys (or any other big supermarket online system)
bt.com (mainly run on weblogic, but mostly customer facing)
I think you will find both of these easily have to cope with 11k+ per min.
And I cannot possibly imagine either of these companies taking a gamble on building using Rails. And Joel was just showing that he thinks with his business head first, putting risk before ‘whats hot’.
I like Rails & Ruby but for enterprise it is not proven compared with (C#, Java, PHP, or Python).
“Rails is nothing without Ruby.” I strongly disagree with that comment! In fact, I would argue that Ruby is nothing without Rails!
If Ruby were such a gem in and of itself then it would not have taken it over a decade to get above marginal recognition. As a scripting language Ruby has never achieved the popularity of Perl or even Python. So were it not for Rails, Ruby would have remained an unremarkable scripting language without JRuby or other efforts that seems to pop-up on daily basis.
“Rails is nothing without Ruby.” I strongly disagree with that comment! In fact, I would argue that Ruby is nothing without Rails!
If Ruby were such a gem in and of itself then it would not have taken it over a decade to get above marginal recognition. As a scripting language Ruby has never achieved the popularity of Perl or even Python. So were it not for Rails, Ruby would have remained an unremarkable scripting language without JRuby or other efforts that seems to pop-up on daily basis.
Sure. Rails is as ready for the enterprise as PHP is.
Whether Rails is *the perfect* tool for the enterprise? Well… only if you think static typing should be put on the stack of useless programming concepts (you don’t care about the IDE goodies that gets you, and you believe unit testing is a perfect replacement for a compiler), if you don’t believe in a strict separation of logic and presentation (you don’t work with separate designers and/ or you just reproduce pages from photoshop designs), if you don’t believe in object orientation in the view layer (you’d rather program to a ‘stateless’ model), if you don’t believe in self contained components (reusability is overrated), etc, then I guess, yes, Rails is the perfect tool for you. 🙂
Sure. Rails is as ready for the enterprise as PHP is.
Whether Rails is *the perfect* tool for the enterprise? Well… only if you think static typing should be put on the stack of useless programming concepts (you don’t care about the IDE goodies that gets you, and you believe unit testing is a perfect replacement for a compiler), if you don’t believe in a strict separation of logic and presentation (you don’t work with separate designers and/ or you just reproduce pages from photoshop designs), if you don’t believe in object orientation in the view layer (you’d rather program to a ‘stateless’ model), if you don’t believe in self contained components (reusability is overrated), etc, then I guess, yes, Rails is the perfect tool for you. 🙂
Lars, you’re right… I need to define what I mean when I refer to an “enterprise app.” In this case, I’m referring to the “ERP” type of enterprise app. Vendors like us, SAP, and others have typically built on a stack, whether it’s proprietary or open. These are the type of pre-packaged apps I was targeting with my article.
Rich
Lars, you’re right… I need to define what I mean when I refer to an “enterprise app.” In this case, I’m referring to the “ERP” type of enterprise app. Vendors like us, SAP, and others have typically built on a stack, whether it’s proprietary or open. These are the type of pre-packaged apps I was targeting with my article.
Rich
Tim, re: Twitter’s traffic. I actually screwed up. I meant to type in 11k requests per SECOND. That’s a lot.
http://www.google.com/search?q=twitter+11k+per+second
Rich
Tim, re: Twitter’s traffic. I actually screwed up. I meant to type in 11k requests per SECOND. That’s a lot.
http://www.google.com/search?q=twitter+11k+per+second
Rich
Re: Joel and his “points”. Joel spends a few thousand words telling you why you need to do your critical stuff in one of the few N + .5 languages, and then admits without irony that they rely primarily on a closed-source in-house Invented Here bastardization of BASIC to write their bug-tracker that noone publicly will admit to actually using. Whatever.
Anyway, Java isn’t going away, PHP isn’t going away, .NET isn’t going away, Python isn’t going away, and Ruby is only going to get vastly more popular. What I would prefer to see is people realizing that and striving for more interoperability. As a heavy Ruby user in a shop that uses Oracle, I’d love to see Oracle actually contribute more than blogging commentary to the Ruby environment — i.e., actually take a look at the OCI Ruby adapter, at the Rails Oracle adapter, or even release a damned Intel Mac Instant Client library since it seems that a sizeable fraction of Rails developers are on Mac and the vast majority of those are on Intel Mac.
Thanks,
Rick
Re: Joel and his “points”. Joel spends a few thousand words telling you why you need to do your critical stuff in one of the few N + .5 languages, and then admits without irony that they rely primarily on a closed-source in-house Invented Here bastardization of BASIC to write their bug-tracker that noone publicly will admit to actually using. Whatever.
Anyway, Java isn’t going away, PHP isn’t going away, .NET isn’t going away, Python isn’t going away, and Ruby is only going to get vastly more popular. What I would prefer to see is people realizing that and striving for more interoperability. As a heavy Ruby user in a shop that uses Oracle, I’d love to see Oracle actually contribute more than blogging commentary to the Ruby environment — i.e., actually take a look at the OCI Ruby adapter, at the Rails Oracle adapter, or even release a damned Intel Mac Instant Client library since it seems that a sizeable fraction of Rails developers are on Mac and the vast majority of those are on Intel Mac.
Thanks,
Rick