Developing with GAE ‘is like being in a straitjacket.’
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:
GAE requires Python 2.5 “which is
You cannot use HTTPS with your own
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.”
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.
It does not work with Python
libraries built on C.
No ‘LIKE’ operator for queries.
Users cannot join two tables.
“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.”
The database’s behaviour is
different in the local development server and the Google
When querying on a table, Ble found
it was “ easy to get the “Too many indexes” runtime exception.”
No query can retrieve over 1000 records.
Users cannot access the file system.
Datastore and memcache can fail, meaning developers must defend
their app against database failures.
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.”
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.