Justin Lilly

I recently moved my hosting from Slicehost to Rackspace Cloud. There were a variety of reasons for switching and decisions to be made along the way. My hope is that the information below will help others in their own decision making process.

Goals

1. Cost Savings

This was really the main point of it all. Rackspace cloud is 1/2 the price of Slicehost. I love Slicehost. They’re really great. That said, they’re not 2x the price great. By trading in my 512 slice, I could have gotten double the server capacity. Instead, I’m opting for multiple 256 servers with backups and such.

2. Easily experiment with new technologies

A benefit of the cost savings of Rackspace is that I can experiment more. Because servers aren’t charged on a monthly basis, I’m not penalized for weekend experimentation. If I want to play with setting up a java stack to muck about with solr and hudson, the cost barrier is relatively low.

3. Test new server setup

One facet of my current job is making recommendations for hosting setups. Keeping an eye on emerging trends and more cost-effective solutions allows me to make suggestions when planning architecture.

4. Gather experience with multi-server hosting setups

I haven’t done a ton with multi-server setups, and the cost of Rackspace cloud allows me to do that. I currently have 2 servers setup, with plans to add at least one more. While this is a far cry from the 20+ servers it might take to run a “real” website, it at least allows me to experiment a few of the more interesting problems like automatic server setup, fail over, and more.

5. Have fun

Most of all, this setup allows me to geek-out without the risks of bringing down an important site, or breaking an existing setup.

Technologies

These are the main technologies I’ve settled on for the initial deployment. They are apt to change, but I’m pretty happy with most of them.

1. nginx

Nginx is a blisteringly fast web-server. While not new, its not as used as apache. I think this is in part due to people’s reservation of learning yet another config file syntax. I think these guys win on the documentation front, which I think is pretty important. They have production configs that are wikis; each keyword links to documentation.

There are various comparisons between it and apache on the speed front, but the main win here for me is it uses less resources than apache. Speed is nice, but not my chief concern.

2. gunicorn

Now here is some interesting new tech. Ported from Ruby’s Unicorn, gunicorn is fast and light on resources.

In an admittedly unfair benchmark, nginx+gunicorn outperformed apache+non-daemonized mod_wsgi 2:1 in pure requests per second. That being said, anyone who was serious about performance would be running mod_wsgi in daemonized mode, which makes it much faster.

3. sphinx

A diamond in the ruff of the Python community, sphinx is an amazing technology that makes writing documentation easy. If your code has proper docstrings, you can pull them into a simple ReST document easily. With just a bit more work, you can have modules cross-linking between functions and classes easily. The result is a moderately attractive site with documentation that’s more readable than api docs.

4. postgres

This is a standard in my tech stack. With fun and excitement happening on the serving side, its nice to know that my data is safe. While I don’t think that postgres will ever leave my stack, I don’t expect it to remain alone for much longer. There are lots of interesting developments coming from the NoSQL sphere. The ones that pique my interest currently are redis and mango.

5. supervisord

supervisord was a completely new thing for me. This essentially allows us to get around running a process and hoping it doesn’t die. Previous solutions to this have included running something in screen, or worse. The syntax for getting things all setup is relatively easy and gives me a bit of piece of mind that my gunicorn processes aren’t going to die.

6. munin

Also a newcomer, munin is the piece that I’m least happy with. First, its ugly. Really ugly. It doesn’t offer an at-a-glance view. Some system for setting thresholds of warnings and errors would allow me to look at only the bits and pieces that need attention. There are a few other requirements for monitoring that I haven’t had a chance to hook into munin yet. Mostly a monitor of cache hits and misses and periodic checks to ensure that my gunicorn processes are active.

7. Varnish

After attending Jacob’s “Practical Django Skills” class, a big takeaway I got was that I needed to be using Varnish. Cody Soyland’s Caching Comparison only further cemented that fact. Its ZOMG fast and is easy to setup for the simple case.

Why you might not want multiple servers

Multiple servers aren’t going to be for everyone. If performance is your goal, 2 256mb servers will be less performant than 1 512mb server. This is mostly due to the overhead of system processes which you have to pay twice (one for each server), leading to a reduction in total usable RAM.

Multiple servers also increase the likelihood that something will go wrong as there are more moving parts. You’re twice as likely as having hard drive failure, twice as many servers to secure, etc. These costs only increase with each server.

Server Migration Checklist

One thing I found missing when I was going to swap servers was a helpful checklist of things to remember. Here’s the one that I finally wrote myself.

• to migrate
• sites
• crontabs
• database
• dns
• backup
• home directories
• web root
• configuration files (/etc)
• other todos
• benchmarks
• backup strategy
• monitoring

Rackspace

My week-long relationship with Rackspace has been good for the most part. There are a few things worth mentioning.

First, their DNS interface is pretty horrible. I had to add ~15 records across 2 domains and it was a slow process. First, it was a bit confusing as it wasn’t similar to Slicehost’s method. To create an A name for a subdomain, I had to fully qualify it, despite only being able to edit records for a single domain at a time. Something that would have helped greatly here would be a bulk-edit interface for adding records en masse.

Second, when I was bragging to a friend of mine about my recent switch, I attempted to walk him through the management console. I say attempted because the entire admin interface for Cloud Servers was down. This was both a bit embarrassing for me and definitely left a bad impression for a possible future customer for Rackspace.

Third, I found that the whole admin process is just a little under documented. The DNS entry screen could have used some helpful hints (DNS is confusing!). An estimated pricing for backups would have been nice. As it stands now, I’m just hoping that its affordable, though it sounds like it is.

The Future

Future plans for my server setup include setting up a Java stack to play around with solr and hudson as well as looking into improvements to the existing setup. If you have any suggestions, questions or comments, let me know.