taylorbarstow.com

I signed up for Slicehost today because I decided to move unbiasd over to their services. There were a few major reasons for the change (which may seem a bit drastic considering that we’ve only been with Rails Machine for a few months):

• Cost we are saving $152/month, a 44% savings
• Uptime this is based on word of mouth, but I’ve heard that Slicehost’s uptime is nearly impeccable. In our few months with Rails Machine, our VMs have gone down two or three times
• Speed I was able to configure my slices so that I get a far larger CPU share than I did with Rails Machine
• Confidence I started out with Rails Machine because I wanted to be able to fall back on their support team if I needed it (I am no expert when it comes to Rails deployment). It turns out that I have only used their support staff for routine stuff - restarting VMs that have gone down, for example - and not for anything specific to Rails. Plus, I am switching to Phusion Passenger, which makes deployment so simple a monkey could just about do it.

These are just my main reasons for switching. There are other benefits, too, like a simple automated backup system, and a great web interface for managing my slices.

Now, onto my review (admittedly, it may be a little early for a review, but at least I can review the signup and install process).

Signup

The signup form is streamlined and simple. You give them your billing information and tell them what kind of slice you want and which OS. From there, a slice is automatically provisioned. In my case, it took less that a minute to receive confirmation that my slice had been created. Ten seconds later I was logged in as root via ssh. This is by far the fastest and simplest signup process I have ever seen.

Lock Down

Since Slicehost gives you a VM with root access, it’s really up to you to make sure it’s secure. That was pretty easy since they give you a simple, easy to use guide describing how to do this. Obviously there are no cookie-cutter security situations, but they give you a great set of defaults that result in a pretty secure box.

Rails Stack

From there I needed to install the Rails stack - in my case, Apache, mod_rails, Ruby Enterprise Edition, MySQL, and Memcached. Slicehost provides guides for everything but Ruby Enterprise Edition and Memcached (and the guides are tailored to your OS, which is nice). REE and Memcached are really easy to install, so I didn’t miss guides for these very much at all.

Staging Environment

After setting up my production-box-to-be, I wanted to go ahead and set up my staging server. Although the production setup was really easy, it did take some time (four to six hours, I would say). This has nothing to do with Slicehost and everything to do with (a) my perfectionism, and (b) my slow, calculated approach to sysadmin tasks (which results from the fact that I am a programmer, not a sysadmin). The second time around would have been quicker (by far), but wouldn’t it be nice if I could just clone the box I had just setup instead?

Luckily Slicehost makes this super easy. First, I turned on backups for my production box (an extra $30/month, but something I wanted anyway). Then I took a snapshot, which took about 5 minutes to complete. Then I created a new VM, and selected my snapshot as the image (rather than a bare bones OS install). The build out took under a minute again. I logged in, tweaked some stuff specific to staging (changed the database name, for example, as well as Passenger’s RailsEnv setting), and everything worked!

So it took about 20 minutes to setup the staging environment.

Conclusions

So far, I am loving Slicehost! I can’t comment on uptime or customer service just yet, but so far this is the best experience I’ve had with setting up a VPS. Slicehost appears to be a best-of-breed hosting service, and I’m glad I found it. Thanks, Slicehost!

Over at unbiasd, we have URL canonicalization problem. You see, unbiasd brings together a bunch of news feeds from various websites and publishes selected articles from these feeds on the homepage. For each recently published article, we use Ice Rocket to search for back links to the article. This is how we power our “blog reactions” feature.

This works great—except for one problem. The article URLs given in feeds are not always the same URLs that bloggers would be linking to. FeedBurner is an obvious example of this. While some bloggers might mistakenly link to a FeedBurner URL, they probably meant to link to the actual article’s permalink instead.

The solution (in my mind) was simple: do a HEAD request on each URL before doing a search for blog reactions. If the HEAD responds with a Location header, then use the referenced URL rather than the original.

This works great for FeedBurner URLs, but there is a problem that I just discovered yesterday. Some sites (including The New York Times) will sometimes redirect you to a login/registration URL before allowing you to view an article. This obviously throws a little hitch into my giddy up: my HEAD request responds with a Location header pointing to a login page, so I go ahead and do a blog search using the login URL. Sweet.

The more that I deal with real-world web content, the more I realize that it is the wild west of data. Pretty much nothing is normalized. Wild hacks are the norm, because sometimes they are the only thing that work. If nothing else, at least this will force me to be seriously pragmatic in my day to day coding.