Google App Engine vs Amazon: Our decision at Vocanic

When I joined Vocanic about 10 weeks back, one of the key mandates for me was to move our applications to a better infrastructure. We were running a old style hosting environment based out of a colo in the US and it just didn't seem like a scalable solution. There was already an instance where one of the apps brought in heavy traffic and brought down the site - so we wanted something that can be scaled at a short notice.

To just complete the context, we are a social media marketing agency - so we run a lot of social media applications for our clients - facebook apps, apps that interact with Foursquare, Twitter and the likes.

As a fan of the Google App Engine (GAE), I was quick to point out that option. As soon as I joined, I showed the engineers some of the apps I had built on the GAE and spoke passionately about moving into that direction.

Then I started evaluating Amazon's EC2 - specially because Amazon had set shop in Singapore recently and we were hoping to ride the Next Gen NBN wave in Singapore (most of our user base is from the region and if we could avoid sending their traffic across the pacific, it would be a boon for us) and I quickly saw why GAE was so much more a restricted environment in comparison to Amazon's EC2.

We decided to go with Amazon EC2 and having been on it for about 6 weeks now and though we were a skeptical bunch in the beginning, I have to admit that it proved to be a good choice. The specific reasons include:

1. GAE psupports two domain landings per app - one from appspot.com and one custom domain (say shreeni.info) of your choice. We often ran apps on multiple custom domains - if the client so wishes. In EC2, we could just hack up the apache vhosts file, but there is no such option in GAE.
2. GAE's data storage engine while being quite well designed for scaling up, is rather a pain to deal with - specially since any single app of ours never scales to a million rows for us, but taken together, they add up to that order. We did not want a store where we could not do arbitrary DB operations - you can't do count(*) operation on GAE, for instance - and we didn't find the trade-off of retraining all our engineers to be GAE-storage-restrictions-aware when we were not going to get any benefits in return. Amazon's RDS storage, running a MySQL InnoDB engine was good enough - and it is fairly trivial to upgrade the storage on that while still retaining all our MySQL-training intact.
3. We did not want to tie ourselves down to Java or Python - the two programming environments supported on GAE - specifically since we are veering towards using PHP as our default programming language (more on that in a separate post).
4. We found some of the restrictions a little too er.. restrictive - timing out page requests after a few seconds, for instance. So, if we wanted to run a cron job that took more than a few seconds, we would have to go and redo the whole thing to fit into the GAE restrictions. Considering that we often launch entire apps within a few days and sometime in few hours, having to deal with altering our thought process just because GAE has that restriction seemed too time-consuming and detracting to me.
5. Of course, serving the traffic from Singapore (one of EC2 colos) was going to make our pages faster than from GAE, which doesn't specify a region from where it will serve traffic. It might as well be doing it from Singapore, but unless it spells it out, we assumed it was from across the oceans.
6. Amazon is showing a lot more innovation - SNS and RDS Read Replicas being launched within the last month, while GAE hasn't shown enough new development in the last year and half I have been following them.

Starting up, one of the considerations we had was the cost of EC2 - almost ~$100 per instance per month for the lowest instance. But just in time for us, Amazon launched Micro Instances - and at ~$25 per instance per month, that was a perfect deal - our traffic, thankfully, fits perfectly on to the micro-instance-plus-RDS architecture.  

We already have a EC2 setup where we have launched a few client applications with higher availability and reliability than in our previous setup and it has so far been a good experience. This is not to say we won't be building GAE apps at all - I still see a role for that kind of environment in our setup, but it didn't fit into what we wanted to be our primary infrastructure base.

In conclusion, GAE takes upon a lot of responsibility vis-a-vis Amazon EC2, but cuts down on a lot of a developer's authority. We chose to have a higher authority in exchange of accepting a higher responsibility.