Bad Week for GAE

Developing with GAE ‘is like being in a straitjacket.’

Jessica Thornsby

Two bloggers share their disasterous experiences with Google App Engine.

Google App Engine (GAE) has been enduring some bad press this week, with Carlos Ble, and Mike Silagadze of Top Hat Monocle sharing stories of how they switched from GAE to EC2. Firstly, Carlos Ble published an article describing how choosing GAE as a platform for their projects reportedly cost the company around 15000€. He plumped for GAE as its PaaS nature means that users do not pay until their website starts getting traffic, which is an appealing prospect for a startup. Mike Silagadze was also drawn to GAE because of its promise to reduce startup costs. However, Ble soon began noticing limitations:

  1. GAE requires Python 2.5 “which is really old.”

  2. You cannot use HTTPS with your own domain.

  3. Requests that take over 30 seconds to run are stopped, which for Ble was a major pain-point: “this has been a pain in the ass all the time.”

  4. Similarly, every GET and POST from the server is aborted if it has not completed within five seconds. Re-configuring it can take this up to a maximum of ten seconds.

  5. It does not work with Python libraries built on C.

  6. No ‘LIKE’ operator for queries.

  7. Users cannot join two tables.

  8. “Database is really slow,” is Ble’s experience, and Mike Silagadze agrees: “just about everything required some annoying workaround. We seriously spent at least 20-30% of our time dealing with App Engine bullshit rather than working on our app.”

  9. The database’s behaviour is different in the local development server and the Google servers.

  10. When querying on a table, Ble found it was “ easy to get the “Too many indexes” runtime exception.”

  11. No query can retrieve over 1000 records.

  12. Users cannot access the file system.

  13. Datastore and memcache can fail, meaning developers must defend their app against database failures.

  14. The maximum values size of Memcache is 1 megabyte, leading Ble to the conclusion that “you need your own software architecture to deal with caching.”

  15. Ble’s team experienced “poor support” from Google, with their website sometimes experiencing 60% downtime per day. Mike Silagadze also complains about downtime, citing 98% availability. Furthermore, there are numerous service disruptions that Google doesn’t report as downtime. An example Silagadze gives are task queue latency going up to ~10 seconds, which is not marked as downtime on Google’s status console.

And the outcome? “Developing on GAE introduced such a design complexity that working around it pushes us 5 months behind schedule,” Carlos Ble says. However, he doesn’t lay the blame squarely at Google’s door, admitting he should have performed more spikes and more proofs of concept before developing actual features, and admits he was “too stubborn just because this great company (Google) was behind the platform.” Mike Silagadze agrees that the problems they themselves encountered were partially their fault for not performing a more thorough investigation prior to adoption, but “ultimately what it came down to was “It’s friggin’ Google! how can their service not be awesome?” and the company got their fingers burnt. Mike Silagadze also admits that GAE is trying to solve “a much harder problem than EC2 or Rackspace or Linode etc,” but that, as a customer, all that matters is the performance and reliability – and GAE just isn’t up to the mark. “Developing with the datastore (their database) is like being in a straitjacket,” he criticises.

Inline Feedbacks
View all comments