Executive Summary: Dropping Google App Engine
Featured Summary: Carlos Ble, a seasoned software developer from Spain, made the difficult decision to drop Google App Engine (GAE) after experiencing months of development delays. In a highly discussed blog post, Ble outlined 13 critical technical and operational reasons why the GAE platform failed to meet his team's enterprise requirements, sparking a massive debate within the cloud computing community.
The Core Technical Frustrations with GAE
Earlier this week, Ble outlined in a blog post the 13 reasons why his company decided to drop Google App Engine. The post had 89,000 views and 158 comments in one day. Some commenters were sympathetic, others chided Ble for blaming Google when the company should have done more research to see if the platform was right for what he and his team wanted to do.
One comment came from Patrick Chanezon, Google Developer Relations Manager for Cloud & Tools. In respect to Chanezon and to clarify his concerns, Ble updated his post but still felt there were enough problems to stick with his criticisms.
Top 5 Issues Encountered During Development
Here are five primary issues Ble lists that give a clear sense of the architectural and operational problems his software engineering team encountered during deployment:
- Outdated Runtime Environments: It requires Python 2.5, which is really old. Using Ubuntu that means that you need a virtualenv or chroot with a separate environment in order to work with the SDK properly: Ok, just a small frustration.
- Lack of Custom SSL/HTTPS: You can't use HTTPS with your own domain (naked domain as they called) so secure connections should go though yourname.appspot.com: This just sucks.
- Strict 30-Second Timeout Limits: No request can take more than 30 seconds to run, otherwise it is stopped: Oh my god, this has been a pain in the ass all the time. When we were uploading data to the database (called datastore a no-sql engine) the upload was broken after 30 seconds so we have to split the files and do all kind of difficult stuff to manage the situation. Running background tasks (cron) have to be very very well engineered too, because the same rule applies. There are many many tasks that need to take more than 30 seconds in website administration operations. Can you imagine?
- Restrictive Outbound Request Rules: Every GET or POST from the server to other site, is aborted if it has not finished within 5 seconds. You can configure it to wait till 10 seconds max. This makes impossible to work with Twitter and Facebook many times so you need intermediate servers. Again, this duplicates the time you need to accomplish what seemed to be a simple task.
- No C-Based Python Libraries: You can't use python libraries that are build on C, just libraries written in python: Forget about those great libraries you wanted to use.
System Failures and Unexpected Downtime
Ble writes that in September, Google App Engine repeatedly failed. He says they faced 500 error codes that some days had the site down 60% of the time. Six times out of 10, users visiting the site couldn't register or use the site.
Ble admits that he should have been more careful but he had confidence in Google.
"For us, GAE has been a failure like Wave or Buzz were but this time, we have paid it with our money. I've been too stubborn just because this great company was behind the platform but I've learned an important lesson: good companies make mistakes too. I didn't do enough spikes before developing actual features. I should have performed more proofs of concept before investing so much money. I was blind."
Community Response and Industry Perspectives
Several commenters were not so sympathetic with Ble's plight. They said he should have done more research or that he had a system architecture design problem.
But then comes this insightful comment from Eugene Ciurana, who literally wrote the book about Google App Engine:
"Carlos, I wrote the first book about Google App Engine programming a couple of years ago. Ever since publication I had several opportunities to speak about App Engine for Python and Java at various conferences; I realized early on that my presentation 'Google App Engine HOWTO' had become a 'things to watch out in App Engine' and ultimately recommended folks to NOT use it for anything serious.
I enjoyed your post and have tweeted because I think it's an important cautionary tale. Most of the work I do has to do with scalability and high availability. While I'd like App Engine to become part of my arsenal, it's now only a marginal part of it, relegated to providing stateless RESTful web services instead of full blown apps. The real app continues to sit in a regular data centre or we put it on Amazon/Rackspace/etc.
About NoSQL systems: Datastore is hardly a good example of a good one. It's good enough for App Engine, but you now know its caveats. Right tool, right job. I'd suggest that, should you identify document- or column-based data storage and retrieval needs, that you take a look at mongoDB and HBase. We're using both in production with large enterprise clients without issues. Take care and cheers! Eugene Ciurana"
In his comment, Chanezon said that many of the points that Ble makes are known by Google. He said the company is actively working to correct the problems.
Chanezon stressed that it is critical that people read the Google App Engine documentation. He said limits have been lifted. The service is designed for highly scalable applications that need to scale rapidly to large volume of users and/or data. He refers to Gri.pe as a successful example.
What do you think? Does Ble have legitimate concerns about relying heavily on Platform as a Service (PaaS) offerings, or should comprehensive proofs of concept have prevented these issues?
Frequently Asked Questions About Google App Engine Limitations
- Why do developers drop Google App Engine?
- Many developers abandon Google App Engine due to strict timeout restrictions (like the 30-second execution limit), restrictive outbound request rules, lack of custom SSL support for naked domains, and specific language runtime limitations.
- What is the maximum request time in Google App Engine?
- Historically, standard HTTP requests in Google App Engine were strictly aborted if they took longer than 30 seconds to execute, which caused significant issues for complex database uploads or background tasks.
- Does GAE support Python libraries built on C?
- In early versions of the Python runtime for Google App Engine, developers were restricted to using pure Python libraries and could not utilize extensions or libraries built on C, severely limiting the available ecosystem.