Today John Gruber linked to a post on the official Dreamhost blog lamenting the state of web-framework deployment on consumer-level shared hosting; while the post itself is largely concerned with Ruby on Rails, the current state of deploying popular (non-PHP-based) web frameworks on hosts like Dreamhost is, well, abysmal. A search for “dreamhost” in the archives of the django-users mailing list turns up nearly five hundred results, many of them people struggling to get Django working, and I imagine that similar searches of list archives for other frameworks would turn up similar numbers of problems.
So. What’s so hard about this, and what can be done to improve the situation?
Well. Actually, “problems”. As I see it, there are three major issues facing frameworks on shared hosting.
First off, the new wave of popular frameworks all make a clean break from a traditional CGI-style model where the application is simply loaded and executed fresh on each and every request; this is a necessary change (reloading a framework like Rails or Django on every request would result in horrific performance), but one that causes headaches for web hosts.
Second, the deployment options are so varied as to be bewildering; even when there’s some sort of standard gateway protocol — as with WSGI in Python — there’s still plenty of room for disagreement on how to actually deploy an application. To run with the WSGI example (and pick on Python a bit just to show I’m not engaging in any favoritism here): I can write an application that speaks WSGI fairly easily, and WSGI applications are for the most part interchangeable. But on the server side, it’s not so clear: should the server learn to speak WSGI directly (à la mod_wsgi)? Should there be an intermediary to bridge the gap, like flup? If so, what protocol should the server and the intermediary use (flup can speak FastCGI, SCGI and AJP, for example)?
Third, the new wave of frameworks are bringing languages like Ruby and Python onto shared hosting for the first time, and with that comes the problem of library support; there’s a whole new world of standard modules hosts need to be aware of and be ready to support if they want to get serious about these frameworks, because asking the typical shared-hosting customer to go out and compile database adapters or image-manipulation libraries (if your AUP even allows that) simply won’t work.
The fact that the deployment model for the new frameworks centers around long-running processes — rather than launching a clean copy of the application on each request — is one that’s hard on hosting providers. Unlike traditional CGI or PHP setups, a framework like Rails or Django or TurboGears simply can’t be run on a “launch a new copy every time” basis; the overhead of loading and initializing the framework makes it unusable in that situation. Having a persistent process which loads the code once and keeps it in memory is the only way this can work.
But hosts have traditionally been reluctant to allow users to launch long-running processes of the type needed to efficiently serve a framework-based application; more than once in my freelancing days, I ran into hosts with automated process monitors which simply killed any user-owned process that stayed resident for more than about thirty seconds. Others have been known to kill anything not on an approved whitelist (read: Rails), which has led to the amusing phenomenon of people renaming their non-Rails FastCGI handlers to dispatch.rb as a workaround.
This situation is slowly getting better, but a whole lot more progress is needed. Yes, a long-running process will chew up valuable memory even when it’s not actually serving a request, but that’s something that has to be accepted; hosts which don’t support this are going to be hosts that don’t get business (or word-of-mouth referrals) from framework users.
One of the reasons behind PHP’s ubiquity is the fact that, for the longest time, the deployment pattern was simple and standard: install PHP and mod_php, tell Apache to use that for anything ending in .php and you’re pretty much done. These days there’s a bit of fragementation in the options — mod_php versus FastCGI versus straight CGI — but they’re all well-documented, well-understood and easy to set up (and, from the perspective of an application author, they all work the same way: just upload a .php file). What’s more, most Linux distributions can set up the whole thing for you with a single dip into the package manager.
Ruby and Python, right now, have nothing approaching this. Yes, Python has WSGI, but see above for why that doesn’t solve the problem. At most, there needs to be one standard stack per language, preferably of the form “install this Apache module”. For Python I think the most promising option is mod_wsgi which, though it doesn’t let you do everything in .htaccess, seems like it’d lend itself quite easily to a plugin for the popular hosting control panels. For Ruby I don’t know; I’m not familiar enough with the various options to be able to form an opinion.
This doesn’t mean that frameworks shouldn’t support multiple deployment options, but it does mean that, for whatever language you’re working in, there should be a standard option and the framework should support it.
import thisThe other big reason behind PHP’s success is that it targets web development specifically, and comes with everything and the kitchen sink. The downside is that PHP’s standard function namespace is horrifically crowded, but at least there aren’t a whole lot of common cases where you have to go out and install a new library just to get something basic like database support.
Ruby and Python, on the other hand, are general-purpose modular languages; this means there are a number of modules which, though necessary for web application development, aren’t included in the standard library of either language. Database connectivity, for example, largely comes from third-party modules; Python only supports SQLite out of the box (and only in Python 2.5 and up), and as far as I know Ruby doesn’t ship modules for any of the “big three” open-source databases (SQLite, MySQL and PostgreSQL) in its standard library.
Some of this could be helped by changes to standard libraries or by more convenient packaging of some of the important third-party items, but if hosts want to get serious about frameworks they need to be ensuring the availability of any key modules that don’t come as part of the language; telling someone to go compile their own copy of, say, MySQLdb for Python is a non-starter.
You’ll note that, of the three things I’ve outlined above, two lay a lot of responsibility on the hosting providers (though if you think that solving the “standard deployment” issue is going to be easy on the framework side, I’ve got a bridge in Brooklyn I’d like to sell you). That’s pretty much inevitable: when a new method of building web applications becomes popular, web hosting needs to change to keep up.
But by and large, this process needs to be a dialogue between hosts who want to offer solid framework support, and developers and users of frameworks who want to make the hosting experience as painless as possible. Neither side can afford to sit back and hope that the other will deal with the problem, and neither side alone has enough expertise or resources to solve all of the issues.
And there are certainly hosts out there which are doing their part: Joyent, with whom this site is happily hosted, pride themselves on Rails support and have also done a lot of largely-unsung work to ensure that Python frameworks will be easy to use on their shared offerings (to the point of contributing patches to key third-party modules so they’ll work on Joyent’s Solaris environment). WebFaction has literally gone all-out, with integrated support for popular frameworks right in their control panel (see their Django deployment screencast for an example).
Going forward, I think that’s going to be the only way to resolve the issues I’ve listed above: the hosts who want to provide a great framework experience will get together with the frameworks which want to provide a great hosting experience, and sit down and solve these issues. And if they’re looking for good solutions to the problems they’re having with frameworks, I’d love to see Dreamhost get in on that.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
Just like the music industry has to get over the idea of CDs and find a new sales funnel, just like the movie corps has to get over the idea of distritbuting movies on discs (completly braindead!) and find new sales funnels (read: internet) the hosting companys needs to find new sales funnels. Shared hosting is deprecated, they should all go for vps hosting.
Sheesh, It is not only the hosting company’s at fault here.
PHP, being such an ugly language, demonstrates how you can be an ugly language but still be used in huge numbers for the www.
Ruby and Python as LANGUAGES need to catch up in this regard. If they don’t, php will happily continue to exist with all its warts (and anything thinking php 6 or php 7 or php x will solve a lot really has not understood the php development process)
Someone elsewhere was making the point that doing these deployments is too hard for developers — at least, much harder than just uploading PHP files. This is a case of great power, great responsibility for the application developers, who can wield their long-running processes for lots of things…
Doesn’t mod_python provide the same sort of ease of use as mod_php?
Note that there’s more to the problem than just a lack of mod_php equivalent for Ruby or Python. mod_php is, hopefully, no longer in use at any major shared hosting provider…it’s just not a very secure way to run applications in a shared hosting environment. Whatever is used, whether it’s mod_fcgid or mod_fastcgi, or some language specific module, it needs to cooperate with mod_suexec. RoR and Django can be setup in a shared hosting environment, if proxying is an option…Virtualmin handles this for RoR by spawning several mongrels, and configuring proxy rules in Apache. It’s not as light as mod_fcgid, but it does execute the applications as the appropriate user.
I’d really just like to see better FastCGI interface support in all of the major app frameworks. It’s not perfect, and the problems with it are well known (though many folks haven’t use mod_fcgid, which fixes several of the biggest pain points in mod_fastcgi), but it does work today for a large class of problems and is available in most shared hosting environments. If RoR, Django, Catalyst, etc. considered FastCGI a primary target for deployment, it would make the lives of folks living in shared environments a lot easier, and would make the kinds of back and forth we’ve seen over the DreamHost rant and DHH’s reply unnecessary.
Joe knows what hes on about. Theres no way you can run django or ruby just run of the mill. They can all access other users data more than likely so suexec or something is needed. The proxying creates all kinda complexities, some of which dont even solve it. Spawning mongrels all over, that has eventually a nice way of killing things.
I find it interesting why folks are having such a hard time getting Django running on Dreamhost. I followed Jeff Croft’s instructions to install several instances during the past few months.
The major flaw with Dreamhost is, as you pointed out, the lack of control over Python modules that are installed and supported.
I have had experience getting Django running on Webfaction however. It was very easy to accomplish. (Practically a one-click install.)
Graham Dumpleton is working very hard to make mod_wsgi meet all the needs of commodity hosting. It is almost there. Once it reaches 3.0 I think we will start seeing it used on commodity hosting. My hope is that webfaction will start using it as well. I like how they have Django deployed, but it is a very memory intensive deployment for multiple sites (1 apache instance per in mod_python), and their new service tier costs are memory/disk/bandwidth based. Using mod_wsgi should reduce the memory footprint by over 70%.
We have been using mod_wsgi for the PyCon website and is has worked much, much better than either mod_python or fastcgi+flup. We had issues with mod_python due to the use of mod_php which was compiled against specific postgresql shared libraries. We could not move to newer mod_python’s for later conferences. So we went with fastcgi+flup, but found that extra processes/threads were slow to start, and a very small bot attack could cause issues. Also flup is not bullet proof to malformed http request headers. As a result we have many zombied processes.
We had a problem with a bot at one point, which turned up a bug in a 1.0 version of mod_wsgi (when compiled for a very old apache). Once we got past that and an issue with some bad django code, we handled a bot attach with over 800 parallel requests. It took 5 seconds for them all to be handled, but they were. These were post attacks with lots of spam (148352 bytes in post header for some). It handles the malformed headers fine.
Last year the schedule app was buckling under the at-conference use. We are expecting twice the load this year, so speed and memory are a concern. I am confident that it will all go well, but have some mod_wsgi apps in front of django planned to deal with excessive load. Catching these issues before django is even it is quite powerful.
Part of the problem, I think, is that some web hosts, including Dreamhost, are so tightly focused on PHP hosting that they don’t provide access to all the other widgets and frobs in the deployment process that you need to tweak to run something like Django or Rails. I tried for months to get a “Hello World” Django app to run correctly on Dreamhost and ran into insurmountable problems every time… I switched to TextDrive (now Joyent) and had a blog written in two afternoons. If you want to run Django or Rails, look for Django or Rails hosting, instead of picking the host that costs less per year than your internet access for a month.
Putting aside the problems of giving access to hobbyists to create long-running processes on a shared host, the fundamental issue is the incredible resource burden that frameworks put on a server. Being memory-resident effectively raises the baseline amount of resources that every site requires.
Traditionally the shared hosting market has thrived because most websites get no traffic at all. The proliferation of open source PHP apps has already raised CPU / Database utilization steadily over years, resulting in poor shared hosting experience (ten years ago shared hosting was usually always snappy, even for Perl CGIs). Hosts like Dreamhost have had to compensate for this by reducing the number of sites per box, and more complex measures to manage load; and even so, there are constantly spikes and “lemon” incidents in the shared hosting world. Now you throw persistent memory requirements into the boat and the whole model breaks down. Immediately you have to cut the number of users per box by 90% just to keep the disk swapping—assuming you don’t take drastic measures like dynamic FCGIs and hope all the sites don’t get a hit at the same time. Then you have a support a bajillion new libraries, and people who don’t know what they’re doing putting in hundreds of difficult-to-resolve tickets a day.
Dreamhost was quick to place the blame on the framework writers, but realistically, fixing the flaws in (e.g.) Rails deployment is much easier than solving the shared hosting problem. I don’t think general purpose shared web hosting has any way of offering a quality framework hosting product. Hosts like Slicehost show that $20/month can buy you a decent amount of fixed resources to run a framework application, but getting that down to $5 a month with support is not going to be feasible. My prediction is that the major frameworks will start to see some specialized shared hosts that solve the support economics by keeping a narrow focus, but even so, people who think $20/month is expensive are not the type of customers who tend to be experts in new framework technology, and you ain’t gonna get rich if they’re bleeding you for support every month.
Getting Django RUNNING on Dreamhost isn’t so bad. Jeff’s tutorial is still a pretty good walkthrough, the Django docs provide info on running it with fcgi, and Dreamhost themselves have a lot of info, considering they don’t officially support it.
It’s KEEPING anything more than a trivially small Django site running that’s the problem.
I don’t think hosting companies have been very helpful. It’s good to hear that Joyent is submitting patches, but they seem to be the exception. Even submitting tickets would be a big improvement. WebFaction has worked around a lot of problems, but working around problems only helps their customers, it doesn’t help other people (I could be wrong, though; it’s possible the individuals at WebFaction have submitted things to these frameworks and I’ve just been unaware of the connection).
For library support the bare minimum is really not that much. You should have any drivers necessary for the databases you support, of course, and probably PIL. That’s not too hard, and it’s just a question of whether the hosting providers gives a damn; nothing but laziness explains missing these packages. Anything more than these packages is not really necessary or helpful.
mod_wsgi seems like the most promising option. It kind of solves the CGI issue with the daemon option, which allows you to limit the length of time a long-running process will stay up which avoids some possibly problematic behavior (e.g., memory leaks). Also this allows applications to go dormant (I think), so low-load applications don’t take up resources when they aren’t being used. I don’t know if it works with or has any functionality like mod_suexec (I’m guessing not) — that could certainly be a problem. Also .htaccess configuration is an issue.
FastCGI should be the right solution to this kind of thing, but I have always gotten the impression that it’s just a piece of crap, lacking a clear design, implementation, or the right features to make it a robust basis for application development. Maybe if people would just start over and reimplement the concept then something good could come out of that.
I can attest to how wonderful an experience it is to run Django apps on WebFaction. Particularly in comparison to Dreamhost. Like Baxter said, it’s not too hard to get Django running on Dreamhost, it’s keeping it going that’s the problem. I have one medium-sized Django-driven site on Dreamhost that’s still going (with only minor hiccups occasionally), but I had to move another one off of Dreamhost almost a year ago due to the site suddenly and inexplicably becoming unresponsive and returning a bizarre error message. I’m still worried that my other site will come down with that case of what I can only call “dreamhostitis.”
Like others, my recommendation is to find a host that “officially” supports whatever it is you want to use, and does it well.
Shared hosts, like Dreamhost, are a dying breed. Their whining just exposes the fact that they’ve been overselling for years and now they can’t do it anymore. Anyone who is serious about development takes the deployment environment into their own hands. I recommend a VPS and personally use one from Slicehost. You get the control and power of a dedicated server at a lower price. You have to get your hands dirty, but it’s an order of magnitude easier to get a Rails or Django app running today than it was at this time last year.
There’s no reason not to get a VPS, I’m particularly happy with Rimuhosting
You should check out Heroku. It’s one-click Rails development and deployment. The system in beta but will be able to scale up as load increases and down when its not. Thus, you pay for it like a utility.
http://heroku.com/
Python needs a concept of a “locked down” module, one which can be used for shared hosting. This way, a persistent python process can be shared for many virtual host, by preloading locked down framework modules, then only loading site specific modules when a request arrives and deleting them upon the end of a request. This will give python the necessary performance/resource consumption on par with PHP.
I like what DHH had to say about this issue at Snakes vs. Rubies (BTW, when is Snakes vs. Rubies II — that needs to happen!). Basically, he said, “Who cares that there’s not a bazillion shared hosts that do great Python/Ruby hosting. How many hosts do you need? Probably just one. If there’s five good ones, that’s all we really need.”
There’s this absurd idea out there that more shared hosts is better. But almost no one uses more than one shared host. So really, you just need a few good ones to choose from. So what if PHP has a million? Do you need a million?
But can you list 5 good shared python/django hosts?
There’s more than 5 that you can get it running, but I’d be hard pressed to come up with 5 that makes it easy, fast and stable.
When looking at how to reduce the time of IT-projects, the focus of organization almost always is on the coding part, regardless of the fact that coding takes up only ten to fifteen percent of the effort (of course, this is largely due to earlier optimalisations of the development.). It is getting the applications that usually is the harder part (well, at least where i work).
As you point out frameworks like Rails and Django are (likewise) focused on ease of development, and while they are doing a great job at it, it’s really the smaller problems that get solved. Easy deployment really deserves the focus now. I find it hard to believe that the smart people that are making these beautiful and elegant development frameworks cannot come up with some kind of packaging framework that makes deployment of python web application as easy as it is for php apps. Once that is done, the hosts will follow.
I posted about this issue several days before the Dreamhost post, and I’ve actually modified my stance slightly since then.
I believed that to be successful, installing an ruby- or python-based app/framework on a shared host had to be as easy as installing Wordpress or another php-based application. In reading this post and others I’ve come to believe that installing an application can be handled by most hosts’ “one-click installer” bots, but there remains the problem of a user of medium technical ability being able to upload and activate modules/extensions to that application.
Just as Dreamhost offers a one-click install of Wordpress, I could see it offering one-click installation of an application on a pre-installed/configured framework system. If the process of uploading/configuring a module or theme can be made easy for the end-user, then I think there’s hope.
I fail to see the relevance of shared hosting in the developer’s world. If you’re really serious about developing a site based on one of the above-mentioned frameworks, then you’ll start out (at a minimum) with a VPS solution like several other posters mentioned. But once you get past hobbyist stage the next step is to get a full-blown dedicated server (lots of hosts offer them for around $100/mo to start).
I’ve been running a dedicated server for years now and if I need a new framework for a client’s project, I just install it. If I want to use a new module or plugin for one of my existing projects, I load it. Most shared hosts dramatically oversell the capabilities of their hardware and hope that none of their customers ever generate any real traffic. On my aging redhat Linux 7 box I’ve got 35 or so static HTML sites, another 10 or so Perl/PHP sites, and 5 of my own RoR sites, and even with mail processing, spam filtering, backup processes and all the sites, I have yet to even break 50% resource usage at peak.
IMHO shared hosting is for hobbyists and “me-too” copy-and-paste coders. If you’re an honest-to-goodness developer you shouldn’t be afraid to get your hands dirty once in a while.
It depends on your market. I don’t know what your opinion is of the developers of Wordpress, but they seem pretty intelligent guys - and they spend their time working their tails off to make software that non-programmers can manage. Regardless of your opinion of their platform, making software for “real people” and hobbyists is a noble cause.
I find this attitude offensive, John. I’m a developer and fully willing to get my hands dirty - but I want to write software that can be used by people who are not programmers - people for whom shared hosting is an acceptable solution.
Maybe these frameworks are never going to fit into a world where CPU and memory use are precious - maybe shared hosting is going to go the way of the dinosaur - but this web was built and populated by “me-too copy-paste coders” who went on to find and build better ways to do things. Heaping scorn on them is just low.
/rant>
mod_wsgi, of course, suffers from its own problems. Embedding the Python process in Apache basically makes your webapps un-sandboxable. It also expands the footprint of Apache, as well as keeping you from exploring alternative servers. mod_python had this problem, and mod_wsgi maintains it since its default setup. mod_wsgi does offer an alternative, the ‘daemon mode’, which so far as I can tell (the protocol is surprisingly undocumented, not even any comments in the code) uses a CGI-like protocol to communicate with spawned app processes over Unix sockets.
My favorite setup is to run an app server (paste.httpserver provides an excellent and stable WSGI server) and reverse-proxy to it from your front-end server of choice. Currently I use Apache’s mod_proxy because I have to support SVN, but I could also use lighttpd or ngnix. And because it’s a standard protocol, HTTP has a full set of tools for debugging, load balancing, logging, et cetera. Sure, you have to have a server running on a port per webapp, and you have to get the external server running (though I haven’t had paste.httpserver crash on me yet except for syntax errors where Python simply refuses to load the code), but this is a solvable problem for someone like Dreamhost who wants to throw a little effort at it.
Good point on the pre-installed modules thing.
Database adaptors are only really the tip of the iceberg. Most Rails apps end up depending on other gems or external modules; I’m sure that Django/Turbogears/other Python apps end up with other dependencies.
The point of “shared hosting” is that everybody gets the same thing. Most companies - especially at the smaller, even more commodity, even more limited end of the market - aren’t going to install some new plugins (especially C-based ones that need compiling) just for your app. And they’re not going to let you do it yourself. PHP never really makes that demand; once it’s compiled and running, everyone can make use of the same code, however nasty you may think it is.
An ideal solution would be to “sandbox” every account - but then you’re getting into serious memory usage and, oh, wait, that sounds a lot like a VPS.
It’s also worth noting that PHP, unlike any other language mentioned here - even Perl - is focused on Web development. The second commenter - “she” - is incorrect in suggesting that the languages should change to match the needs of web development. The languages are designed as precisely that: languages, agnostic to where they’ll end up or what they’ll be used for. Changing them to match a single use case would compromise them.
I always compare it to the “cheap food” argument. “Cheap food” is usually an illusion; it’s not that other food is more expensive, it’s that this food is unnaturally cheap, usually due to some kind of mass-production move at the cost of quality. Commodity hosting has become insanely cheap but, frankly, it’s an illusion. Just because mod_php makes this possible doesn’t mean it’s the right solution for everyone; if you look at the Python/Rails/Java/.NET communities, you’ll see that almost all their web development prefers to be structured around the “application server” approach. And that’s going to take more memory, and allow the developer more control over their environment. In the end, a server you don’t have any control over isn’t much use in the long term. It’s great that PHP exists - I use it for lots of quick/dirty implementation, precisely because I can dump things onto any webserver in the world - but its simplicity of deployment comes at the cost of many other things. We shouldn’t presume that the cheapest, simplest option should become the norm.
ASP.NET has been following this model for some time now, and is available on shared hosting. We have a few MonoRail (kind of like Rails for C#, but they’re diverged into their own idiomatic form now) apps deployed in a shared hosting environment and they are fine.
Granted, most shared hosting providers limit the medium trust, which means no unmanaged code or COM interop, but most Web sites don’t need that anyway. The whole trust model is basically the result of a historically mangled permissions system on Windows, but it also provides insurance within code itself; ie, limiting the use of reflection to prevent maliciously self-modifying code, limiting the use of sockets and the registry, etc. (Does the open source world have anything like this? I used to do a lot of PHP work, and other than “safe mode” [groan] it didn’t.)
The point is that this part of the problem is at least solvable—without going for the 45-pound sledehammer that is VPS.
Just my two cents, from someone who’s worked for both PHP and “true blue” companies.
There are just too many different ways of running newer web apps such as Rails and Django, yet none of them are that easy.
Now as an administrator trying Django for the first time you read the documentation and try mod_python, as this seems to be recommended. The first thing you do is install mod_python as you’ve never tried a Python web application before and the first thing you notice is that the web server ends up dying with segmentation faults due to MySQL library problems.
Now compare this to some PHP application where the administrator installs mod_php and it pretty much works as expected. You can tweak any settings in .htaccess files under Apache with directives such as php_flag. It’s also easy for mass webhosting, any requests for websites which aren’t used that often won’t take up much resources - just a little bit of time with Apache/PHP on page requests.
We need a solution for all other languages frameworks. Although mod_wsgi is yet another potential solution it doesn’t help me if another user of my server wants to install Ruby on Rails, as mod_wsgi is just for Python! Now mod_fastcgi is reasonable as is mod_fcgid, but neither are exactly perfect. Sadly .htaccess files don’t allow much control for users with the FastCGI solutions.
I went with mod_fcgid, but it’s hardly the best solution if you want to put many sites on a single server.
Rails/Django are both very powerful web frameworks, in fact so powerful they are probably way over the heads of any hobbyist / newbie
A light rails clone like CakePHP on the other hand does about 80% of what rails can do but is far more likely to run without any issues whatsoever on all of the decent shared hosts.
There are a few good rails clones out there and they are getting better all the time - I wouldn’t be at all surprised if they end up replacing rails.
I was wasting so much time trying to compile mod_python with the right libraries on my Linux box that I ended up spending a few dollars on a WebFaction account where everything was already installed for me. Everything just works out of the box.
Maybe I’m crazy, but I like to think that if you can program in languages such as Python and Ruby, you can setup a simple web server, ffs.
I’ve been with hosting at highspeedrails.com for years (It used to be called zettai) with no hassles at all. The support is fantastic and the uptime has been over 98%. I haven’t used PHP or Rails on their service, but I’ve done both Zope and Django hosting there and they made it very very easy.
What about MediaTemple’s GridServer containers? Isn’t that the way to go with “advanced” shared hosting? You get all the shared hosting convenience, plus an application environment that lives outside the rest of the shared resources. I agree that a developer should know how to set up a proper server or VPS, but it’s a good commodity to have security and e-mail and ftp, etc, already set-up and taken care of. One less hassle to deal with.