Is the Enterprise world Rails ready?
Antonio Cangiano April 20th, 2008
When searching the web for the words “Rails” and “Enterprise” you’ll find countless discussions about whether Rails is Enterprise ready. Some argue that it is, especially thanks to the extendibility offered by its plugin support, while others claim that realistically it’s not. “Is Rails Enterprise ready?” is the wrong question, I’d rather ask if the Enterprise world is Rails ready. Let me clarify this point.
David Heinemeier Hansson gave a brilliant talk at Startup School, in which he didn’t speak about Rails. He spoke about business models, 37signals’ way of charging for subscriptions to web apps, the odds of a startup becoming the next Facebook and so on. He rarely mentioned Rails, but that presentation can tell you more about Rails and the Enterprise, than most of the essays that you’ll read on the topic.
Companies like 37signals love their way of doing business. They solve problems by creating valuable services for the long tail of small business owners, and of course charge them for doing so. They are all about productivity and having fun in the development process. That’s the kind of environment in which Rails was born. It came out of the necessity to increase productivity, while offering an enjoyable experience to the web programmer, and Ruby, as a language, was the perfect choice for that.
Ruby on Rails was created so as to be an almost perfect match for what David and 37signals needed. They weren’t facing the issue of legacy databases, so they were able to choose simple conventions that made sense for them. They had a server to host their applications, so the whole shared hosting issue that many people complained about was not a problem for them. Rails’ cost of scalability was not troubling for 37signals, because they had paying customers. More scalability issues for companies like 37signals, mean more money rolling in from paying customers; so just throwing hardware at it can be done without frowning. It means that business is good. Given the choice of picking development speed over application speed, in these types of contexts development gains are often a much bigger payoff.
Rails is opinionated because it was tailored for the needs of 37signals and their products. If your web application and business model is somewhat similar to that of David’s company, then Rails is hard to beat and there is little to complain about. Rails will evolve and continue to improve, but most of its focus will remain on 37signals and the needs of similar companies. David prefers to work on real world web applications and introduce the most useful lessons back into the framework, not having them be designed by a committee. That’s why there isn’t a Rails, Inc. and why new Rails features are not arbitrarily introduced to satisfy any possible usage of the framework by the thousands of companies who employ Rails.
Aside from its origins, Rails became a sensation in the web development world. It had a deep impact, just think about how it made the MVC paradigm an accepted and almost expected reality in other web frameworks that come out later. So with everyone jumping on the bandwagon, people started to consider Rails for use in environments that it wasn’t really created for. Namely the so-called Enterprise world.
This is why the question “Is Rails Enterprise ready?” is the wrong one to ask. It questions whether Rails has evolved yet to the point of being able to support developers within the Enterprise. Rails has no expectation of being a good match for the current Enterprise world. It doesn’t now and won’t in the future. There is however an expectation that the Enterprise world will become more Agile and embrace simplicity over complexity. In other words, let’s ask if the current Enterprise is ready for Rails. The answer I’m afraid is not a sound “yes”. Rails can be used in the Enterprise world, and a good part of my job is promoting its adoption exactly in this kind of environment, but there is little point in complaining aloud about the fact that Rails doesn’t have great support for certain features out of the box.
When Dave Thomas made his famous keynote at RailsConf, in which he pointed out important issues that concern the most “enterprisey” customers, David did not embrace the idea at all. The reason is simple, in his eyes, it’s the Enterprise world that needs to change, not Rails.
As a matter of fact, Rails can be successfully used for complex scenarios, and it’s probably still much more productive than using an overkill like J2EE, in most cases. But it’s not natural, it forces you to take advantage of (maintained or not) plugins, and the whole ecosystem around Rails is not very supportive of the needs that you may have.
What happens to those developers who “saw the light” and would like to introduce Rails into an environment where it’s still someone else, or a different team, who defines and handles the database? Plugins help, integration with Java through JRuby is a viable alternative too, but overall the experience can be rather frustrating. The Enterprise, especially when dealing with existing data, can be very slow to adapt. And we all know that fighting against bureaucracy within your large company is anything but enjoyable.
It seems to me that most of the Enterprise is not Rails-ready, just like it’s still hardly Agile-ready. The current compromise is meeting at a middle-ground. Developers add enterprisey features into Rails through plugins, or adopt JRuby on Rails, while at the same time trying to simplify as much as possible in order not to go “against” Rails.
But is there a better way? In the Ruby world, I see two viable possibilities but neither is easy or quick. The strongest one is a Ruby framework that takes into account the needs of the Enterprise, from scratch, while still remaining easy to use like Rails. It would be the equivalent of what motivated the creation of Rails, in a different, substantially more complex environment. The second option is a fork of Rails, specifically targeted towards the Enterprise/Corporate sector, with a rewrite and expansion of a few key components in order to make it a superset of Rails.
Whoever creates either of these frameworks well, will be worth their weight in gold.
