complains that deploying a Rails application is a sticking point for most:
For the average person, making choices about web servers and configuring proxying through Apache is too much.
…and he’s absolutely right. If I didn’t run my own server, I’d probably have ditched RoR by now. The only problem is what else would I have gone with?
Sure RoR has it’s fair share of unique problems – although I believe the benefits you gain far outweigh these issues – but anything except middle of the road PHP and vanilla HTML will have their own problems. Want to run ASP.NET? You either need Windows hosting (£££) or fight with mod_mono. PHP5? Not all hosts have switched to it, and you might be limited with libraries/versions etc. Want to use Postgresql instead of MySQL? You can poke holes in any language/platform/framework, and all of them have their own workarounds and solutions.
Deployment is part of the bigger picture, and one that often gets overlooked during development (especially for smaller webapps). If you’re going to pick an up-and-coming technology like RoR then you need to consider deployment issues. It’s not going to work with your generic hosting provider, and even if they do offer Rails support then you’ve still got the problems that come with sharing a server. If you’re lucky enough to get one with Rails and decent performance then you’re still restricted to their versions.
As far as I’m concerned, running your own server is the only way to go. For the (small) premium you pay to get a UML server over a virtual host, the freedom you get is more than worth it. Of course not everyone has the knowledge/skills or desire to run their own box, so there will always be a niche for companies like RailsMachine, EngineYard and Planet Argon and it’s up to them to streamline deployment for their customers.
So what if you want freedom of your own server but not the hassle of running it? Well maybe there’s a business opportunity there…
Tags: hosting, Linux, rubyonrails