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
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

  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

  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.

comments powered by Disqus