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.
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.
Rails made MVC acceptable? Really? What did everyone else do before Rails shined the light on this separation of concerns first named in the Smalltalk world in the early ’80s?
chromatic, no one is claiming that Rails invented the MVC paradigm. What I’m saying is that Rails helped it to become mainstream and commonly used amongst web developers. And this is undeniable.
That’s completely deniable; the Java Pet Store is just one example of MVC in the web world long before even the invention of Rails.
I can believe that plenty of people first learned about MVC from Rails — there’s always a steady stream of novices who have to learn from *something* — but you distort history to claim that MVC wasn’t well understood and well accepted among web developers before 2005.
Is there a better way?
What about a framework that merely encourages choice of ORM, View Engine, etc, like Merb? That would solve many of the issues mentioned in this article.
@chromatic, I see where you’re coming from but I assure you that there isn’t any intention of distorting history. In fact, I believe we are saying the same thing (more or less). Yes, MVC existed before Rails, yes there were plenty of skilled web developers who were aware of the architectural pattern before 2004/2005. Read my sentence carefully though: “it made the MVC paradigm an accepted and almost expected reality in other web frameworks that come out later”. Most of the web frameworks created after Rails were influenced into adopting the MVC pattern because Rails did so very successfully. The pattern was accepted and well understood before 2005, but that doesn’t mean that it was as common and expected in other frameworks, like it is today. ActiveRecord wasn’t a new pattern either, but Rails made it more popular/mainstream as well. In any case, this is a tiny detail out of a larger article whose main point has nothing to do with MVC. Do you have any comments on Rails and the Enterprise?
@Joe: a modular framework makes life easier in the sense that you can rewrite a single component, and still take advantage of the rest of the framework. You also take advantage of more possible combinations for the ORM, template engine, etcetera. Merb is a promising framework, and I’ve been watching it closely. But it will still require that the crucial components that can be plugged in, are written with enterprise needs in mind.
I wanted to take a look at the Dave Thomas keynote to see how many of his concerns have been addressed in the meantime, but couldn’t find it online. Anybody have a link?
Here you go, Stefan: http://www.scribemedia.org/2006/06/30/dave-thomas
There’s another way you didn’t mention: quit your boring, frustrating job at Big Enterprise Co. and start working at New Exciting Startup company 🙂
I don’t believe Rails is or will ever be a good fit in the “enterprise”. Why? The enterprise is where existing data lives. While Rails is fantastic for writing standalone web apps, it sucks when trying to use legacy data. Rails strengths are its weaknesses in the enterprise. This is why I can’t understand how big business latched onto Rails so quickly. Rails also won’t fit it in well at my company. Besides the fact it doesn’t work well with legacy data, it also doesn’t work with our development process. DBA’s have control over the databases. They create them. Rails migrations would never fly here.
I believe Django has a better chance at working in the enterprise. Unfortunately, we don’t have a DB2 driver yet for Django (thats for another discussion that I brought up last month on the django-developers site) but I think Django works much better with existing data than Rails does. Django does have one glaring weakness however. It only supports a single database at a time. This needs to be addressed.
I’m currently using ColdFusion at work and it definitely works good in my company. Our data is in DB2 that sits on IBM mainframe. I can connect to as many databases as I want. I just wish Django had this capability as I find it much more productive than ColdFusion.
So it really comes down to use the right tool for the job. Is Rails enterprise ready? Not in my company. But thats not a criticism. Its not a fault with Rails, its just that Rails wasn’t designed for my environment. And thats fine. If I need a standalone web app, I won’t hesitate to consider Rails.
Thank you Antonio…
The question whether the enterprise is ready for Rails is interesting and relevant. My company started out evaluating Rails and did a rather systematical analysis. We concluded that Rails would outperform our existing web development which is java, but we needed to adapt to the existing infrastructure to use it for more than simple standalone webapps.
The biggest challenge was how Rails would integrate with existing (legacy) systems. These are all java (pojo) and oracle, with a lot of stored procedures and prepared statements. The system architecture is layered with frontend (web and java) clients and backend servers all behind firewalls and proxy’s.
Layers: browser | proxy | web clients | backend servers | database
For security reasons there is no way we will put a Rails client directly in front of the database. The rails client has to be connected to a backend server, and most transactions between the client and server must be cryptographically encrypted and signed.
Another requirement is that the business logic must be available between the backend servers through transaction handlers.
We examined 3 different solutions in a pragmatic way, all with the mindset of keeping as much good Rails stuff as possible. These include migrations, Rspec and CI, MVC and AR.
1) Jruby backend and REST client. Declined, because jruby on the backend side is not trivial to intergrate with the existing java servers. REST client doesn’t support relationship like has_many.
2) DRB (jruby) backend and Rails client. Declined, because DRB backend and java ingeneration does not work properly. RPC creates lot of traffic between client and server.
3) Rails (jruby) client and java server. This works fine, with a twist!
To elaborate a bit on 3. To be able to use as much as possible of Rails we created a “java adapter”. Most of Rails is “in memory” operations and all the good stuff in MVC and html-helpers is nice. But the beauty lies in AR. Ultimately AR is persisting data with normal CRUD operations. Our “java adapter” hooks in on these operations, and connects to a java (socket) server which “knows” what to do base upon naming conventions. The persistence is all prepared statements in the java server, and the server handlers are available in pure java to all the other backend servers. We can use our secure transaction framework for encryption and signing as well.
To be able to use the full Rails stack during development, the developers have the usual mysql local database and uses migrations. These are handed over to the DBA which performs the art of database refactoring. We developed utilities that create code for the java server handlers. This is done by parsing the SQL created by AR in combination with the CRUD operation.
The first application based upon this “framework”, a rich UI RBAC client, is going live in June.
So my conclusion must be that “our enterprise” is ready and so is Rails !
The real criticism I can hold against the Rails core team is their failure to provide solutions for large rails applications (in complexity). Enterprise apps tend to be large with lots of special cases and crazy requirements, and Rails doesn’t have anything to help with this problem. It’s still better (in my opinion) than anything else out there, but it needs some help.
Ever try coding an application with 50 controllers and 75 models? Then you’ll know what I’m talking about.
We just need some sort of conventions to deal with it. So its still easy to create a todo list, but also easy to package pieces of functionality up into self contained entities.
But since the Rails core team and 37 signals targets simplistic, stripped down web applications (which I like!), they have no use for these types of features in the framework.
In fact, the Rails core is downright hostile to Engines, a Rails framework extension that seriously tried to deal with the problem. They also added components in, screwed up the implementation, then told us all that no one should ever need components anyways and just use spaghetti code consisting of before_filters everywhere and partials.
If Rails core cared about the issue enough, they would have integrated Engines or built their own alternative in order to allow Rails applications to be packaged up as components and working. There’s a reason the Django community is taking off, its because they solved this problem. Django apps are extremely scalable in functionality because you can partition pieces off into components that encapsulate large chunks of functionality and work well together.
But the state things are in now, Rails Engines is unusable, Rails is difficult for large apps, and people would rather blame the enterprises for not adopting the attitude that all web apps should be variations on todo lists and blogs.