Why Ruby on Rails Isn't Enterprise Ready
Sep 05, 2006There is a very clear reason as to why Ruby on Rails isn’t “Enterprise Ready” yet, and guess what? It’s not a technical issue.
Disclaimer: The commotion between the posts of Joel Spolsky and DHH has finally died down. Here’s my take on the underlying issue. No architect astronaut theories here.
It’s Not Technical
Ignore the questions of Rails ability to perform, scale, and make a killer breakfast burrito. There are plenty of examples out there that Rails can make great web applications that meet large user demand. How Rails scales has been explained before (hint: just like any other LAMP stack, in a very boring, predictable fashion).
The Rails community is also moving quickly to flesh out niches with plugins so that Rails can interface with just about anything. I’d argue that Rails is meeting developer needs in niches faster than Java or .NET did during their early growth stages.
So please ignore the sniping between the Rails, Java, and .NET camps. All it really amounts too is a bunch of chest beating about who’s language and framework is cooler. It is not a debate about the Enterprise.
It’s The People
The term “Enterprise Ready” has always been a people issue to me. Programmers in the trenches are the ones that care about all these technical questions, not the managers that make the decisions. Managers want to know things like:
- Are there vendors for this technology that will support us?
- Can we pay for a support contract?
- What other big visible projects have been done with this technology?
- Will we be able to put together a team easily?
That last question is arguably the most important. Most big corporate IT departments these days are understaffed and overworked, so new projects almost always have some contractors on the team. I can guarantee that vast majority of placement and consulting firms will give you blank stares if you tell them you need a Ruby on Rails developer.
Managers of Enterprise projects want safety. They want to know that they can get people for the project easily. They want a 3rd party to blame (or sue) when things go wrong. They want their butts to be covered when the massive $100k vendor solution doesn’t come close to meeting performance and scaling promises.
Because it happens all the time. I’ve seen proprietary vendor solutions (ex: ATG Dynamo) fall flat on their face and receive nothing more than head scratching from the vendor support team. I’ve seen J2EE applications struggle to deal with 10 users when they need to handle thousands. When things like that happen there needs to be someone to point a finger at.
Being Enterprise Ready isn’t a technology term, it’s a people term.
Organic Growth and A Better Question
Right now Rails doesn’t have a big corporate persona to stand behind. It’s an open source project with thousands of developers globally that contribute back to the core team with plugins and tools. This has resulted in a great community that has pushed out some impressive web applications. It has also allowed Rails to grow in a grass roots fashion through word of mouth. There isn’t a big corporate marketing strategy. There aren’t huge training camps for the big consulting firms. Ruby on Rails is a technology that will be brought to the masses by individual developers who are passionate about it and work it into their day jobs.
Quite frankly, I like the way Rails is growing. This begs the question: Do we want Rails to be Enterprise Ready?
[Update: Relevance LLC provides a good analysis of Enterprise class software vs. software that runs the Enterprise. I think it brings up some good points.]