Shared hosting is not a ghetto
In the wake of the Dreamhost blog’s post on Rails and shared hosting, there’s been a bit of a meme going around with respect to deploying frameworks like Rails (or Django, or TurboGears…), and which more or less consists of people asking why, if you’re using one of these frameworks, you’re not just ponying up for a VPS or dedicated server. After all, it’s not like the offerings these days are that much more expensive than commodity shared hosting.
There are some problems with this attitude, some of which are elegantly characterized by a comment on Twitter developer Alex Payne’s post “Shared Hosting is a Ghetto”:
people who are living in ghettos are, you’ll find, rarely there because they’re just too cheap to move to the nicer parts of the city.
Let’s run with that and explore why shared hosting, despite the average developer’s distaste for it, is still a necessity and — I believe — a good thing for the modern frameworks to play nicely with.
The hidden cost of dedicated hosting
The first thing to realize is that a VPS plan that costs $20/mo. isn’t actually that cheap; it comes with ongoing costs in terms of systems administration and maintenance that, frankly, a lot of people don’t have the time or budget for. Yes, you get the operating system preinstalled and maybe a nice control panel to configure services, but that’s just the starting point: you also need to monitor security and bugfix updates for all of the software running on your server, and be ready and able to upgrade or reconfigure in response (and even with nice package managers like apt, this is still a non-trivial job).
For that you either need to have some sysadmin skills or have the budget to hire someone who does, and that means your cost, either in time spent doing this work or money spent paying someone to do it for you, goes up. You can get “managed” dedicated servers, but again your cost and complexity go up.
When you take things like this into account, typical shared hosting suddenly starts looking a lot more attractive to the average individual or small business that’s trying to set up a Web presence: they only need to worry about the things that directly pertain to their own site, and the host takes care of the rest of the server environment. And back when I did freelance work, I steered a lot of clients toward shared hosting solutions (including Dreamhost, though, in the interest of disclosure, I never made any significant referral money from them) for precisely this reason: it let the client focus their budget on the things they actually cared about.
Is dedicated hosting overkill?
Also, for the vast majority of individuals and small businesses out there, dedicated hosting is really much more than they’re ever likely to need; standard commodity shared hosting can handle their application loads and traffic levels just fine.
For example, this blog runs on a Joyent Accelerator, which is a virtualized slice of a beefy Solaris server and gives me root access to go in and configure whatever I want. But it’s overkill for what I’m doing here; even when I’m being linked up by a bunch of popular blogs, shared hosting would be able to handle the load with ease. I bought the Accelerator plan for other reasons (including the fact that, as a geek, I just love having cool things to play with).
If I were helping a typical small business to work out what they need for their Web presence, and doing a realistic assessment of their expected traffic levels and resource utilization, I’d probably recommend shared hosting; most people simply have no need for what a VPS/dedicated plan offers, and the additional costs outlined above would make such a plan a bad choice for them.
Flexibility
Ultimately there’s only one argument I can think of in which VPS/dedicated hosting comes out ahead for the needs of the typical web site: the freedom and flexibility to run practically anything. When you’ve got the keys to your own box (or a virtualized slice of one), you have absolute control over what runs on it and how, and that can be a big attraction.
It means, for example, that you can set up Apache or any other web server, and build exactly the set of extensions and modules you want. It means you can tune the database until it sings. It means you can throw up a memcached instance and give it the memory it needs without worrying about per-process limits. It means you can add or shut off services at will. It’s the ultimate power trip for the average web-dev geek.
But is this level of flexibility necessary for running a framework-based application? Absolutely not. The only reason people recommend dedicated hosting for frameworks like Rails is the fact that, right now, we’re all still figuring out how to make the shared-hosting equation work. Back in the days when consumer-level hosting didn’t typically offer CGI access or limited it to canned pre-installed scripts, people would recommend moving up to the next tier of hosting if you needed to run custom stuff Today you’d be laughed at if you recommended dedicated hosting for that.
I fully believe that within a year or two, the same will be true of the new wave of frameworks: there are promising solutions already nearing maturity (and several hosts which are already doing a great job of helping them along), and worries about whether you can deploy a framework on shared hosting will be as antiquated as a previous age’s worries about whether you can use mailform.pl.
Why I care about shared hosting
Thinking back again to my freelance days, when I mostly worked in PHP and Perl, one fact stands out: I almost never wrote a full application for a client. Most of the time I took something off the shelf, reconfigured it, wrote some stuff on top of it or maybe wrote a plugin, and that was that.
Part of the reason for this was the availability of software I could hack on, but a bigger part was simply that writing an entire application back to front, in those languages and at that time, simply wasn’t an option: grabbing a canned app and hammering it into the right shape for the client’s needs, or (more often) something close enough to work, was the only thing that could deliver on time and within budget. I ended up making some pieces of software do things they were never intended to do, sometimes badly, but it was always faster and cheaper than bespoke development.
Today, though, I’d never dream of working that way. If I were freelancing today, I’d simply pick up a framework and build out an application tailored precisely to my client’s needs, and I’d be able to meet both deadlines and budget requirements. By dealing with the common, baseline problems like database interaction, templating and URL dispatch, frameworks free up developers to, well, develop.
But if it’s too hard to deploy a framework-based application on the kind of commodity hosting that most smaller clients will have, then they’ll never see the benefit of it. They’ll keep hearing, and believing, that custom application development is too expensive and takes too much time. They’ll keep getting square pegs hammered into round holes. They won’t ever get applications that really fit their needs. And that’s a case where everybody loses: clients get crappy sites and developers get crappy jobs, and nobody’s happy.
Shared hosting is not a ghetto
Shared hosting is and likely will always be an appropriate choice for many types of sites: individuals, small businesses, non-profit groups with tight budgets, all sorts of use cases that aren’t necessarily glamorous but exist and make up a huge percentage of real-world web development. There are still plenty of cases where I’d recommend VPS or dedicated hosting to a client who has the budget for it, but shared hosting works and is a good solution for an awful lot of people.
And while it’s currently hard to deploy a lot of framework-based applications on a lot of shared hosts, that doesn’t mean framework developers should just ignore the problem or hope that someone else will solve it, or that people who want to take advantage of the power and flexibility of modern web frameworks should be forced into hosting solutions that don’t otherwise suit them.
Like I said the other day, what’s needed is an ongoing dialogue between hosts and framework developers, to sit down and solve the various issues in ways that work for both sides. Comments about how shared hosting is a “ghetto”, or how the customers at shared hosts are just too cheap to get real hosting, bespeak ignorance at best and arrogance at worst, neither of which contribute anything useful to discussions of a real problem being faced by real people.