Sachin Rekhi

As many of you know, I have been a huge fan of Google App Engine. I love the vision and truly believe its the first real platform-as-a-service as opposed to the other dominant cloud platform Amazon AWS. While AWS has significantly moved the industry forward with on-demand virtualized instances and cloud storage, it has not developed a fully scalable runtime environment comparable to Google App Engine. Sure Google App Engine only supports a very restricted use case and set of technologies, but constraints can be liberating. If the scenario fits for your web app, the freedom to focus on your app and not on infrastructure and scaling is very compelling.

Thus far I've created a variety of small production apps on app engine, including this blog, TuneChimp, and MonkeySort. I am now in the process of embarking on a large project and have been planning on using Google App Engine for it. However, I have run into a variety of shortcomings in GAE that currently and for the foreseeable future seem insurmountable. It has led me to have to reconsider my platform choice for this project and at this point relying on Amazon AWS (or an alternative cloud platform) seems like the ideal option.

For those also considering building applications on top of Google App Engine, I wanted to discuss these shortcomings so that you can make an informed decision when making your own platform choice.

Urlfetch Requests Can't Take More Than 10 Seconds
Google App Engine in Python requires you to proxy all your third party HTTP requests through their urlfetch library. They have created a lightweight wrapper around it to allow python developers to use their typical urllib and urllib2 interfaces. However, the urlfetch library still has a hard restriction that enforces a deadline on any outgoing HTTP request to a maximum of 10 seconds. While in many scenarios this restriction is fine, when building a mashup application that leverages third party APIs (whether its Twitter, Facebook, YouTube, or others), there are many scenarios where you realistically run into this urlfetch deadline restriction. Some APIs allow you to break up long requests by paging, which allows you to get below the 10 second limit, but this often needlessly complicates your code. In addition, some third party APIs are simply poorly written, don't allow paging, or have high latencies that make it impossible to get meaningful results within the 10s limit.

While Google has already increased this deadline once to the higher 10 second limit, they have provided no roadmap or expectation of increasing this deadline further.

Requests Can't Run for More Than 30 Seconds
In addition to the urlfetch restriction, any web request cannot take longer than 30 seconds. This is the entire time allotted to responding to a request. The scenarios for longer requests typically are not user web requests, but instead offline tasks that periodically call to third party APIs to get the latest data and cache it locally or any other kind of offline computation. While Google App Engine has provided the scheduled tasks and task queue APIs to create a nice facility for this, the fact that any individual task can still only take 30 seconds severely limits the possibilities. While in many cases you can smartly divide the tasks to less than 30 second increments, this again requires significant management of task breakdown which may create needless complexity in your application. Or there many even be scenarios which just simply can't be modeled as tasks that must return within 30 seconds.

Since Google App Engine is designed primarily to respond to user web requests and not designed to be an engine for significant offline processing, there is no roadmap for significantly increasing the amount of time an individual task can take.

Can't Open Sockets To Arbitrary Ports
Given that Google App Engine is a constrained runtime environment, it has an understandable limitation of preventing you from opening sockets on arbitrary ports. This restriction is necessary for security and scalability and Google can only be expected to enable these scenarios by providing their own wrapper libraries for each desired scenario. However, this leads to restrictions on important scenarios. For example, if your application wants to incorporate email and connect to an IMAP server, then you have no ability to do this on GAE.

While Google does plan to eventually add additional services to their capabilities, there is no plan for providing a general capability for opening sockets.

Can't Support HTTPS on Own Domain
Google App Engine allows you to launch applications on either their appspot.com domain at a custom subdomain or to host your application on your own domain through Google Apps. However, if you want to handle HTTPS requests, it has to be done on the appspot.com domain. You cannot support HTTPS on your custom domain. This is a significant restriction since it prevents you from providing a fully secured experience for a user on your own domain.

Given technical limitations, Google has not provided a roadmap for when this issue will be solved, leaving people who require this functionality to simply find another cloud platform.


While I love the promise of Google App Engine, each of these technical limitations in the current platform with no clear roadmap to enable these scenarios has led me to abandon Google App Engine for my next project. I plan to continue to monitor Google App Engine developments and see where it goes as I still believe it is a great platform for certain constrained scenarios. But I plan to spend my time now investigating Amazon AWS and Rackspace Cloud.