Ask 100 enterprise developers (who are probably using Java or C#) if Rails is ready for the enterprise. My guess is that 75 will say no, 1 will say yes, 9 will say "I don't know", and the other 15 will ask "What's Rails?"
Assuming my estimates bear some resemblance to reality, this tells us a couple of things:
- A good chunk of enterprise developers have never even heard of Rails, or have heard of it but don't really know what it is.
- Many enterprise developers don't know enough about Rails to understand its qualities, weaknesses, and enterprise-readiness.
- Many enterprise developers believe that Rails is a toy framework. This is often attributable to DHH's "Build a blog in 15-minutes with scaffolding (WHOOPS!)" screencast, which was a great way to generate excitement about a new framework, but didn't demonstrate the depth and breath of Rails.
- Very few enterprise developers believe that Rails is capable of solving enterprise problems, or have a religious devotion to the familiar and tend to fear change.
So why aren't more enterprise projects using Rails? I think one reason is that Rails has only been around for about 3 years, and enterprises are notoriously slow at adopting new technology, especially radically new platforms like Rails. There are a lot of enterprise Java shops still using JDK 1.4 or 1.3! (If you're one of them, my condolences.) It's often a struggle just to introduce a new dependency on an open source project -- something as small as Apache Commons to something as big as Hibernate. Lawyers are called in to examine licenses. Security auditing may be done. Integration concerns are brought up. And then you have to actually teach dozens or hundreds of developers how to use it.
Another reason for the lack of enterprise adoption is the FUD around Ruby's and Rails' performance, scalability, and maintainability. Sound familiar? These are the same arguments that dogged Java for years, and still do today in some circles. Religious debates abound between static vs dynamic typing, compiled vs interpreted, explicit vs meta-programming magic.
I think the answer is that it depends on the enterprise, and it depends on the problems. (Answers that begin with "it depends" sound like a cop-out, but in this case I think it's true.) A good craftsman uses the right tool for the job. Sometimes Java is the right tool, and low-level JDBC is needed to integrate with legacy databases. Sometimes you really need great Unicode support, and I agree that Rails is really lacking there. But there are plenty of cases where a greenfield project needs be produced quickly featuring all the latest hotness (Ajax, REST, and the rest), or a legacy database can be migrated into something Rails-friendly.
Posts
11 comments:
It is true that often it is astonishing on how developers in large organisations could ignore what is happening "outside" their context and will don't know what Ajax, RoR or TDD mean. However, events like a new Ruby IDE by CodeGear could help change this.
Franck, thanks for your comment. You might be right about the CodeGear release drumming up some interest. However, I don't think it will make enterprise developers aware of Rails. Anyone with their finger on the pulse that would find out about 3rdRail *probably* already knows about Rails. That said, any news is good news!
The FUD around Ruby and Rails' performance is not FUD. Ruby and Rails are incredibly slow and do not scale.
In 1995 Java was too slow
In 2007 Java is the fastest thing outside C/C++ and isn't far from them.
In 1995 Ruby was too slow
In 2007 Ruby is too slow.
See the difference? IronRuby and JRuby are not going to solve this either. The JVM and CLR are just not suited to Ruby.
@anonymous: Ruby might not be as fast or scalable, but it usually doesn't matter once you remove the biggest bottlenecks. It's amazing what you can do with just some simple SQL tuning (using correct indexes, eager fetching to solve n+1 selects, etc.).
Look at Twitter. They handle thousands of requests per second. They got to the point where the database was the bottleneck, and needed support for distributed databases, which was implemented as a plugin within a few days.
Ruby also hasn't gone through the paces that Java has to improve performance at the low level. I think we'll start to see improvements with the visibility Ruby has enjoyed lately.
Finally, performance and scalability aren't always important, even in enterprise software. Sure, it would be nice if you could guarantee high P&S out of the box, but you really can't on any platform. It takes work, and it's been done on Rails.
I wrote a post about this same topic back in June -> http://oracleappslab.com/2007/06/04/why-ruby-on-rails-is-the-perfect-framework-for-building-next-generation-enterprise-apps/
I think it's ready for the enterprise. We're using it.
Well, the thing is that developers usually do not decide technologies in the enterprise. The technologies are decided by enterprise architects. Secondly. Ruby do not have some enterprise features. Scalability etc. could be seen on twitter, but it does not have SSO, kerberos, connectivity to servis buses etc. The only place for rails in enterprise could be prototyping. So, in enterprise it is not a development tool, but kind of analysis tool. For more, see Ruby on rails in enterprise
Roman, you're right that front-line developers don't usually get to choose the technology. But they do have some influence if they have any opinion and communication skill whatsoever, unless the architect is just a tyrant. That's not a reason for the lack of enterprise Rails; it's an excuse.
Rails plugins provide support for SSO. And support for OpenID.
I'm not aware of ESB support, but that's probably a good thing. ESB, to my understanding, is the new CORBA -- a proprietary, non-standard mess. Instead, Rails favors REST for loose-coupled integration and web services. I'm far from an expert in this area, but from what I've seen REST is simpler, more useful, and more likely to be around in 3 years.
Why do you need Ruby on Rails when you have PHP and big load of PHP frameworks?
PHP is extremely mature and proven technology and nowadays it powers Web 2.0. Everybody knows that PHP is more scalable than Java, Python, Perl and deadly slow Ruby.
@pcdinh: There are a lot of reasons to favor Rails over PHP-based frameworks. First, PHP has been around a while, but the MVC/Rails-inspired frameworks haven't. CakePHP is probably the most popular, and it's younger than Rails.
Also, Ruby is a real object-oriented language. That doesn't mean much to a lot of PHP developers, but it does in the enterprise. I'm not going to get into the pros and cons of OO -- but it can be safely stated that OO is the paradigm of choice. Much of the elegance of Rails is directly attributable to Ruby.
Again, the performance/scalability FUD. Even if it were true that PHP is more scalable than every other technology known to man (which it's not), and everyone knew this to be a fact (which they don't), performance can't be considered out of context. Look at where the bottlenecks are (hint: use a profiler) -- are they in the interpreter or somewhere else? Usually they're somewhere else, like the database, or web server, or some crappy code that happened to be written in *insert language*.
Don't you think a big part of this is that most large enterprises have: 1) a large infrastructure of servers, supports tools, etc already in place, and 2) have committees that actively try to standardize the platforms that any new applications are built on.
Introducing an entirely new language and platform needs to be a sure bet (not just an experiment) for most enterprises to go for them. Couple that with needing new servers and uptime tools to support and it's just not obvious why to bother with the experiment. In a large organization, there's just not that much free bandwidth to go figure out patches and everything else for a whole new set of servers and runtime support tools. The reality is that there is a large investment in the current infrastructure. There is not any agility to just suddenly change that out. Try swapping WebSphere for WebLogic. That is a political nightmare. Now you want to go with a bunch of companies no one has heard of? "Enterprise" servers (the ones they'll use) generally need to have companies and large call centers for IT to buy/use them.
I personally think Rails is great, as is Ruby, but if your entire workforce is trained in a certain language, is it really "more productive" to switch everything to something new? I don't think the cost savings of Rails really warrant that change yet.
Last point, enterprises do not have deeply skilled "programmers" at their disposal. They normally have "coders" with a limited skillset. I know of several companies right now trying to figure out how to standardize all the different ways Java is used in their enterprise (Spring, Spring MVC, Spring WebFlow, Struts, Stripes, Tapestry, Hibernate, Torque, iBatis, etc, etc), let alone pull Java out for something that doesn't even resemble what their developers are familiar with.
Rails might be easy to generate simple applications in, but getting Ruby right, optimized and readable in a large project is not something I would be comfortable throwing a bunch of "coders" at. Try taking ctl+space and reference navigation from current developers in an enterprise. Now try explaining AOP to them. Having fun yet? Now go for mixins and explaining that you will be able to call seemingly unrelated methods from your code. Good luck. I don't know many people who would "get" that very quickly.
Blake, thanks for the comment. I agree with you 100%. This goes back to my statement that enterprises are very slow at adopting new technology. I didn't go too much into the causes for this phenomenon, but you nailed a lot of it.
Maybe a good way to say it is that Rails is ready for the enterprise, but the enterprise isn't ready for Rails? ;)
Post a Comment