Behind the Project: Pic A Fight

"MARBLECAKE ALSO THE GAME" was written on our top pics page in pictures of letters briefly on Saturday. :D

So, I did the server stuff for pic a fight. I had done some work with AWS scripting for bringing up PHP sites, so changing the scripts to work with rails was pretty simple.

This was my first Rails app ever. Well, that's sort of not true. A year ago I tried Heroku for a "hello world" type rails app to see what the fuss was about. It took me about 2 hours to get it deployed b/c of some cryptic ruby/gem/rails/whatever version number compatibility errors blah blah blah... and it kind of turned me off to the whole system. It was not a simple as advertised. I have a lot of sysadmin background, and this was more complicated than just doing it myself...

With the PHP sites, I could spawn a stock Ubuntu Server AMI and use a boot script to have the server install the necessary packages (php, mysql, apache, etc), fetch a repo from github, and configure apache to start the web site.

With Ruby 1.9.2/Rails 3 I tried to do the same thing, but there are no Ruby1.9.2 native packages, and having RVM compile and install from source took FOREVER, so it was not useful to start from a blank AMI. I took some time to install all the necessary junk to make a boilerplate Ruby1.9.2/Rails3 AMI and saved it.

So, now I can do basically the same thing as the PHP sites, just starting with the RoR AMI.

So, when I saw traffic start to spike, I sat calmly at my terminal and typed:

    $> ./launch_picafight.sh 5

which booted 5 more instances which came online and hooked themselves up to the load balancer all in about 2 minutes (for bonus points I had the boot script send me a Notifo notification after each server was online so that I knew they had come up).

Learning ruby/rails was enough of a challenge for this project that I didn't learn the black art of deplyoing using something like Capistrano. In this case I had two options: if we needed to deploy new code I could either ssh to each live server and issue a 'git pull' or just launch new servers (which would automatically get the latest code) and nuke the old servers when the new ones came online. Both of these worked fine.

As for cost, having the extra 5 servers running for about 12 hours cost $1.20 according to the AWS pricing guide. Now it's back down to 2 micro instances (it could really run on 1 probably, but we're on the Free tier so one of them is basically free anyway).

I'm not exactly sure how Heroku dynos work, but according to their pricing, a comparable price would have been $0.15/hour which in Heroku terms is 4 dynos. This means 4 Thin processes responding to requests. We had 7 servers each running apache with 5 prefork servers... so 35 total processes running for the same price.

Am I comparing apples to apples here? I'm not sure; please correct me if I'm way off.

Anyway, the point is I know my sysadmin junk and it was just simpler to do it this way with AWS than to learn a whole new system... plus now we have entire servers which we can run other background stuff on for no extra cost. Dunno, I know a lot of people absolutely love heroku, but I've found the tradeoff of flexibility for simplicity to be a bit too steep.