After Dreamhost's post that shared hosting with Rails is too difficult to implement, and DHH stated that he (mostly) agrees</a>, Peter Cooper of RubyInside suggested that we need a mod_ruby. Now I’m going to chime in with a few thoughts of my own.
First, shared hosting of Rails apps is entirely possible with the tools that exist today. The proof: Heroku is doing it. Of course we’re not much like a traditional shared host, and in fact we try to avoid calling ourselves “hosting” at all. But hosting is certainly a substantial part of the service we’ve created, and in terms of implementation, our free accounts are set up in what is basically a shared hosting environment.
How have we managed to accomplish this, especially given that Heroku as a product is less than six months old? First, there’s the matter of focus. We’re hosting Ruby, and Ruby on Rails, only. Being focused allows us to tailor the infrastructure to that setup exactly.
Second, Heroku is opinionated software. Even just saying “Ruby on Rails” only tells you two components of the stack. RoR can run on different operating systems, different databases, and be fronted by different webservers. When you put your app on Heroku, you don’t get a choice of operating system, webserver, or database. Instead, we make those choices to create a unified stack that we can verify works together flawlessly. The idea is that individual app developers need not waste time making these decisions, and instead can dive straight in to the part that matters: coding their app.
You could compare this approach to an Apple computer vs. a PC built from OEM parts. An Apple has all the parts preselected and verified to work together, from the network chipset right up to the operating system and all the software that comes with it. Building a PC from parts, one has many choices to make, and sometimes the choices will be incompatible with each other. For DIY-types, building your own system can be a lot of fun, or let you build unusual configurations to fit specific needs, like creating you own MythTV box. Heck, I’ve built dozens of PCs, mostly servers, over the years. But if you’re not looking for DIY fun, and you just want a computer that works as quickly and easily as possible, the Apple approach is clearly the better one.
Finally, I’d like to say that mod_ruby is probably not the right path for the Ruby world. It did work extremely well for Perl and PHP, true; but Ruby frameworks are different. (Mainly because, well, they are frameworks, not just a language. mod_ruby would probably be fine if people wanted to write raw Ruby scripts to generate HTML directly.) Perhaps mod_sinatra or mod_camping would be more appropriate. Still, it seems to me that Apache is probably near the end of its lifecycle, so investing time and energy in developing modules for it does not seem terribly worthwhile to me.
Perhaps the message here is not that we actually need a mod_ruby, but rather that we need a component that solves the same problem that mod_perl or mod_php did: drawing together several components in the toolchain to make the infrastructure easier to deploy. My personal feeling here is that something that makes use of the growing availability of virtual hosting is a better choice than trying to pursue the shared hosting model so popular in the era of PHP. Smarticus suggests that Rails users favor VPS hosts for deployment, and I wholeheartedly agree with that. But further, perhaps the equivalent of mod_php for the Ruby world is going to be some sort of tool that makes it easy to stamp out prebuilt VPS instances. EC2onRails seems to be one possibility (I haven’t used it myself). I’d suggest to others looking to solve this problem that VPS hosting is going to be the key to creating a mod_ruby-alike solution for the Ruby world.