Carlos Ble is a developer out of Spain. His company decided to use Google App Engine (GAE) but dropped it after what he said were months of delays.
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.
Here are five issues Ble lists that give a sense of the problems his team encountered.
- 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.
- 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.
- 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?
- 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
- 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.
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.”
Several commenters were not so sympathetic with Ble’s plight. They said he should have done more research. That he had a design problem.
But then comes this 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 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 an example.
What do you think? Does Ble have legitimate concerns?
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.