Slingshot Business Hosting
As many of you know, I’ve been deploying quite a few Ruby on Rails apps lately — to shamelessly plug a few, there’s Meople (a db/app server and web server setup), some personal sites (my own server) and quite a few Highgroove Studios client’s sites.
When I first started “helping” Derek Haynes of Highgroove Studios a long time ago to deploy Rails applications, we were learning along with the big providers. We survived the pre-1.0 Rails days (0.13, 0.14 !) and some crazy Apache and lighttpd setups. We’ve come a long way, from the days of shared hosting and the wonderful resources at TextDrive, DreamHost, and other hosting providers. We’ve since moved on to deploying on our own servers, dedicated and co-located for complete control. Along the way we’ve contributed to many guides, pages, and the community — most importantly, many of the pages on the Official Ruby on Rails wiki. Most notably, we’ve learned a few tricks or two about hosting business-class apps that demand serious attention to detail.
We’re ready to give back to the community, and provide a much needed service. We’d like to introduce Slingshot Hosting - specialized Ruby on Rails Business Hosting for Serious Applications.
When we did price comparisons for managed hosting plans, we realized that these plans are an incredible value — we’re focusing in on what we excel at, so we can afford to do it on the cheap. We’re not having to support a million different open-source packages on several different platforms like some managed hosting providers — we’re supporting Rails Business Hosting, something we know and love.
I recently had a talk with a fellow ATLRUG member about the difference between shared hosting with a big provider and venturing off to your own server. If you’re ready to rock and roll and adminster a Rails app yourself, the shared hosting plans from some of the big vendors are awesome. However, the first time your system crawls to a slow because of incoming mail processing setups or logs filling up, or lighttpd misconfigurations, a spider hitting your main controller, or anything else, you’ve gotta dig in and fix it yourself — assuming that it’s you and not someone else on the box that caused it to happen. With Rails development, administering is a huge hidden cost/time-waster.
Highgroove Studios (and some of our clients) started out on shared servers and quickly became frustrated when we couldn’t figure out why our servers were running slow, our lighttpd directories weren’t resolving, dns was timing out, fastcgi instances were dying/crashing and our bandwidth was just s l o w. We went down the path of setting up our own boxen at a data center and have lived through the administering side of things enough to learn the tricks and tips, and aren’t looking back.
To be completely honest, I think the hosting market is changing substantially. It used to be that space, bandwidth and the number of domains/e-mails were deciding factors. But what’s the difference between having 500 e-mails and 1000 e-mails or 10GB instead of 20 GB, if you’re only going to use 3 e-mails, or 100k for space for a rails app. What Rails app (or two or 3 or more do you know that uses more than 10 Gb) unless that’s another part of the service they’re offering to users (space for user storage: photos, etc.). Have you ever used 2GB of e-mail? There are already services for these kinds of things that are cheap. Think Gmail for Domains and Microsoft Live and YahooMail for mail, and Amazon’s storage services, Flickr/ImageBasket/Photobucket and others as well…. These things are cheap, and should be outsourced. We’re not trying to compete in that market for cheap hosting.
These numbers and stats shouldn’t be the deciding factor in going with any bigger hosting vendor versus us. The important factors in deciding between Slingshot Hosting and anybody else are that Slingshot Hosting servers are ready to go using capistrano, externally managed fastcgi processes (and mongrel), lighttpd, webstats, incoming qmail processing, and a bunch of rails developers who’ve seen it all behind it 100%.
If I was thinking about running a Rails app that my business depended on (which I do), I’d be hoping there was a guy named Derek or Charles who runs an app or two or 3 or more that I could call or e-mail to make sure it’s running smooth.
