7 ms·

Why Google AppEngine sucks

48 points by gasull 17y ago

blasdel 17y ago
There are many things to hate about AppEngine, but this is not one of them. You're being aggressively rate-limited because your account does not have billing set up. If you only have the free quota to work with, they place continuous limits on resources to keep you from exhausting your daily supply early.
- th0ma5 17y ago
  They also have an algo that protects against DDOS, and allows for resources to be allocated as organic (even viral) activity increases... see their article about load testing to see that you can get quite a lot of load by staggering it.
  - BarsMonster 17y ago
    I am not denying the fact that it scales. I am saying that on the per-box level it is slow. And if you get slashdotted, you get that "synthetic" load peak, which might not be handled by scaling.
    - th0ma5 17y ago
      I have been slashdotted, and as best I could tell it handled it fine. The individual nodes are slow, especially since the box is probably doing lots of other things. If the task can be parallelized, this is a non issue. If it can't (which may be insanely rare) then it won't work. Most of my time on AppEngine has been trying to make smaller and faster requests that handle less and less data.
- ntoshev 17y ago
  Even with billing, GAE expects gradual ramp-up of traffic, as would happen in the real world. Your app will fail to scale if you hit it with an artificial blast of benchmarked requests because the back-end wouldn't know to fire up more instances.
  - BarsMonster 17y ago
    In our extra tests we get 15k real user hits (get an image on a popular web-site front page, 3req/sec average), and then added 2 servers with load generators to get to 50-80 requests per second. We haven't noticed when it auto-scales (that was "proper" sharded counter application). Probably it never scales on non-billed account (but we were far from our limits).
boggles 17y ago
"Disclaimer: This article is not about "I am so clever, Google is so stupid". This article is about some Google AppEngine problems (or peculiarities) which might not be obvious for newcomers." It would be nice if the title reflected that sentiment.
- mseebach 17y ago
  It would be nice if the article reflected that sentiment.
- dchest 17y ago
  The same article in Russian (click "RU") has the following title: "Should you use Google AppEngine?". The author has been lost in translation.
  - BarsMonster 17y ago
    I wasn't lost. In fact, original article was initially written in English, and then translated to Russian. It was intentionally corrected according to the taste of the place where it was published in Russian (to reduce "trolling").
    - derefr 17y ago
      So western tastes prefer trolling?
      - ilyak 17y ago
        Nope, it's russian tastes that would make a huge trollfest of such a title.
    - michaelneale 17y ago
      So what we are left with is link baiting in english? no thanks... it doesn't need a title like that.
adrinavarro 17y ago
And what about a real-life case? I'm pretty sure that a GAE app can handle much more than what is said in the benchmarks. In fact, firing 100 connections to the same host from the same IP is not a real-life case for me. But I'm pretty sure that those 50 req/sec (for example) aren't shared among all connected users to the same GAE host. Anyway, I still don't like GAE but I think that this is not a real reason. And I personally don't like giving everything, including my apps, to Google. Uh.
lecha 17y ago
Anyone care to share a real-life GAE performance figures non-free billable account on a long running application?
- DocSavage 17y ago
  This just came out today: http://googleappengine.blogspot.com/2009/09/agile-paddling-with-app-engine-lessons.html http://googleappengine.blogspot.com/2009/09/agile-paddling-w... "All in all, we saw over 1,000,000 page views from 93 countries around the world, and experienced incredible stability and scalability from Google App Engine even when we were spiking 350 requests per second during the finals." Dave Westwood of BuddyPoke shared a few slides on his performance: http://files.meetup.com/1135107/BuddyPoke_AppEngine_Stats.pdf http://files.meetup.com/1135107/BuddyPoke_AppEngine_Stats.pd... It's a little hard to parse w/o more description, but basically he's done well serving what seems to be a large % of Brazil with a low error rate. IMHO, the best ways to use app engine rely on (1) memcache to iron out any timeouts or datastore issues, and (2) a relatively rich client front-end so any problems on back-end can also be handled in a user-friendly way (like Gmail).
shimon 17y ago
AppEngine is about scalability, not performance. You shouldn't care if a single hit on an AppEngine app takes 2 or 4 times as long as a single hit on your dedicated sever; the point is that when there are zillions of hits, your server will be on fire while AppEngine will be taking about as long as it did for that first hit. Of course, this scalability is not without cost. Most web apps don't need this kind of scalability, so the development tradeoffs (like the chance of datastore operations failing, or the inability to wrap transactions around arbitrary sets of data operations) may be too much trouble. AppEngine isn't for all web apps, and many web apps would be very painful to shoehorn onto AppEngine. Still, if you want to build your app so it scales like Google's own apps scale, AppEngine can help get you there.
- richardw 17y ago
  There seem to be a few cases where it's far more than 2 or 4 times as long. I've found deleting takes ages - a couple hundred items can take a minute of "CPU" time. Discussions on the forum mirror that. I think it's great for many individual users doing tiny operations that don't interact with others, which my use case is. But you will be surprised by some of the performance characteristics. See this example: http://gaejava.appspot.com/ http://gaejava.appspot.com/
- jbellis 17y ago
  > You shouldn't care if a single hit on an AppEngine app takes 2 or 4 times as long as a single hit on your dedicated sever Actually, you should. Latency matters. Google knows this. http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-...
stevejohnson 17y ago
As someone who does a lot of work in App Engine, my only gripe at the moment is that you can't delete an app once you create it. It exists forever.
- bemmu 17y ago
  I've started naming my App Engine apps bemmu1, bemmu2... so that if I decide to discontinue an app later, I can just reuse one without having an old name still attached to it. It doesn't really matter as the name would not usually be visible to a user.
  - stevejohnson 17y ago
    I am more concerned about the 13(?)-app limit.
    - nickjohnson 17y ago
      10, but we can increase it if you ask.
      - mshafrir 17y ago
        Who would we contact about an increase?
- babyshake 17y ago
  You can always just empty your app.yaml or edit your code to return an empty page...
  - stevejohnson 17y ago
    But the app is still stuck in your list.
damagednoob 17y ago
I question the benchmarks that are claimed for a single server. 10 million hits per day? Stackoverflow is just approaching 1 million hits and they've just recently gone to 2 web servers. Never mind the fact that the DB is also on a different server. The fact is that my argument makes as much sense as author's does. It all depends on what your server is doing.
- BarsMonster 17y ago
  The idea of GAE: we do care about scaling instead of you. What I prefer to think: write proper code, and you will never need a cluster (probably not for all cases). There are just 6.5billions people on the earth, so the maximum traffic is limited anyway.
  - babyshake 17y ago
    App Engine thinks about a lot of thinks for you, besides scaling, and the roadmap suggests that it's going to continue to go into Amazon's territory, such as by hosting large static files. I'm still holding out on built-in full text search, but recent releases like a task queue and an XMPP client are nice additions.
bemmu 17y ago
The issue is not with GAE, but his code. It may look simple, but actually it is not using the data store as one should. Putting a single entity repeatedly does not scale, this is well documented. In the case of the example, a sharded counter is needed: http://code.google.com/appengine/articles/sharding_counters.html http://code.google.com/appengine/articles/sharding_counters....
- BarsMonster 17y ago
  Yes I've seen it. But it clearly shows some of the problems existing with GAE. It is possible to avoid them, as well as most of the rest, but we cannot deny the fact that there is a problem. Also, there are read-only tests which are also not amazing.
  - Confusion 17y ago
    But it clearly shows some of the problems existing with GAE No it doesn't show that, because what we're discussing here is is not a 'problem'. The GAE datastore behaves this way by design. It may mean that some developers will experience problems, because they are not used to a non-relational database, but that only means they have problems. It doesn't mean that GAE has problems, unless you wrongly suppose, as you seem to do, that any developer should be able to use the GAE datastore as his relational-database-intuition tells him to.
thetrumanshow 17y ago
A tale of two projects: One one project (RoR), I have a BIG-IP load balancer in front of 4 dedicated servers, one of which is a db. On another project, I am running a straight Python app on App Engine. Guess which one I've had to wake up in the middle of the night to fix on occasion...
- sanswork 17y ago
  The one where you haven't outsourced the server support? Thats not a win for GAE so much as it is for outsourcing your server support.
  - thetrumanshow 17y ago
    Oh, I see. Then, guess which one doesn't require me to seek out and contract a firm to handle my admin for me?
    - sanswork 17y ago
      The self managed RoR one. For the GAE one you sought out someone to host and manage your servers for you and contracted Google to do so.
      - thetrumanshow 17y ago
        Well, technically, both have some level of management which is bundled with the services. Ex: I don't have to literally put out fires if one breaks out in the server room. App Engine's management service by contrast is very tightly bundled to the hosting services... so tightly in fact that the cost of the management service they provide is exactly proportional to the cost of the resources I consume. It's a great deal. But we are getting off into the weeds here. App Engine simplifies server admin for me. I have never had to personally 'bounce' anything for any reason. I don't worry about running out of disk space. I don't have to worry about sweeping out the sessions (on disk or db). I don't have to setup database replication. I don't have to configure rolling archive tables to improve the speed of access to the most commonly accessed data on a large table. Being a solo operation, App Engine is ideal.
kljensen 17y ago
Clearly GAE does not "suck". We've used it a lot, e.g. [1]. The principal advantages are: - No sys admin. You can just focus on your app. - The datastore (BigTable) is slick. Write and read times are independent of how much shizzle you stick in there. - They're constantly making it better. E.g. the free quotas got more generous after a few months; and the new built in cron and off-line processing (taskqueue) support enables more complex apps. Clearly not for everybody. We love it. Does not suck. [1] http://news.priorsmart.com/ http://news.priorsmart.com/
gfodor 17y ago
In related news, I am getting CapabilityDisabledExceptions on my AppEngine site, with no warning or explanation. Edit: Yup, AppEngine is hosed! http://code.google.com/status/appengine/detail/datastore/2009/09/22#ae-trust-detail-datastore-put-error_rate http://code.google.com/status/appengine/detail/datastore/200...
- gfodor 17y ago
  Ah, its scheduled maintenence. Would have been good if they put that somewhere on the status page!
  - nwinter 17y ago
    They recommend that you subscribe to their downtime-notify group. They post well in advance of scheduled maintenances, and have recently put up a schedule of all such maintenances through the end of the year. It's easy to miss the "you should subscribe here" info though.
jaspertheghost 17y ago
It's about time. Google AppEngine (Map Reduce, GFS, etc) has always lacked behind the Dynamo architecture in terms of winning developer mind share and specing the right features. The inherent problem with Google App Engine is it's not backwards compatible with existing system.
- tybris 17y ago
  By Dynamo, do you mean Amazon's service oriented architecture?
onreact-com 17y ago
Any headline like "x sucks", "x is bull####" or "x is dead" should be changed to "x critique" to establish some civility of discussion. This type of "pulling a Calacanis" headline is sheer link bait and rarely meant to stir an honest discussion.
- scrame 17y ago
  Agreed, along with "Did X just Y?" which is usually just speculative linkbait.
tybris 17y ago
I don't know why I would use an application platform that doesn't let me do anything, but I found it to be very useful as a reverse proxy.

48 points by gasull 17y ago

There are many things to hate about AppEngine, but this is not one of them. You're being aggressively rate-limited because your account does not have billing set up. If you only have the free quota to work with, they place continuous limits on resources to keep you from exhausting your daily supply early.

th0ma5 17y ago
They also have an algo that protects against DDOS, and allows for resources to be allocated as organic (even viral) activity increases... see their article about load testing to see that you can get quite a lot of load by staggering it.
- BarsMonster 17y ago
  I am not denying the fact that it scales. I am saying that on the per-box level it is slow. And if you get slashdotted, you get that "synthetic" load peak, which might not be handled by scaling.
  - th0ma5 17y ago
    I have been slashdotted, and as best I could tell it handled it fine. The individual nodes are slow, especially since the box is probably doing lots of other things. If the task can be parallelized, this is a non issue. If it can't (which may be insanely rare) then it won't work. Most of my time on AppEngine has been trying to make smaller and faster requests that handle less and less data.
ntoshev 17y ago
Even with billing, GAE expects gradual ramp-up of traffic, as would happen in the real world. Your app will fail to scale if you hit it with an artificial blast of benchmarked requests because the back-end wouldn't know to fire up more instances.
- BarsMonster 17y ago
  In our extra tests we get 15k real user hits (get an image on a popular web-site front page, 3req/sec average), and then added 2 servers with load generators to get to 50-80 requests per second. We haven't noticed when it auto-scales (that was "proper" sharded counter application). Probably it never scales on non-billed account (but we were far from our limits).

boggles 17y ago

"Disclaimer: This article is not about "I am so clever, Google is so stupid". This article is about some Google AppEngine problems (or peculiarities) which might not be obvious for newcomers." It would be nice if the title reflected that sentiment.

mseebach 17y ago
It would be nice if the article reflected that sentiment.
dchest 17y ago
The same article in Russian (click "RU") has the following title: "Should you use Google AppEngine?". The author has been lost in translation.
- BarsMonster 17y ago
  I wasn't lost. In fact, original article was initially written in English, and then translated to Russian. It was intentionally corrected according to the taste of the place where it was published in Russian (to reduce "trolling").
  - derefr 17y ago
    So western tastes prefer trolling?
    - ilyak 17y ago
      Nope, it's russian tastes that would make a huge trollfest of such a title.
  - michaelneale 17y ago
    So what we are left with is link baiting in english? no thanks... it doesn't need a title like that.

adrinavarro 17y ago

And what about a real-life case? I'm pretty sure that a GAE app can handle much more than what is said in the benchmarks. In fact, firing 100 connections to the same host from the same IP is not a real-life case for me. But I'm pretty sure that those 50 req/sec (for example) aren't shared among all connected users to the same GAE host. Anyway, I still don't like GAE but I think that this is not a real reason. And I personally don't like giving everything, including my apps, to Google. Uh.

lecha 17y ago

Anyone care to share a real-life GAE performance figures non-free billable account on a long running application?

DocSavage 17y ago
This just came out today: http://googleappengine.blogspot.com/2009/09/agile-paddling-with-app-engine-lessons.html http://googleappengine.blogspot.com/2009/09/agile-paddling-w... "All in all, we saw over 1,000,000 page views from 93 countries around the world, and experienced incredible stability and scalability from Google App Engine even when we were spiking 350 requests per second during the finals." Dave Westwood of BuddyPoke shared a few slides on his performance: http://files.meetup.com/1135107/BuddyPoke_AppEngine_Stats.pdf http://files.meetup.com/1135107/BuddyPoke_AppEngine_Stats.pd... It's a little hard to parse w/o more description, but basically he's done well serving what seems to be a large % of Brazil with a low error rate. IMHO, the best ways to use app engine rely on (1) memcache to iron out any timeouts or datastore issues, and (2) a relatively rich client front-end so any problems on back-end can also be handled in a user-friendly way (like Gmail).

shimon 17y ago

AppEngine is about scalability, not performance. You shouldn't care if a single hit on an AppEngine app takes 2 or 4 times as long as a single hit on your dedicated sever; the point is that when there are zillions of hits, your server will be on fire while AppEngine will be taking about as long as it did for that first hit. Of course, this scalability is not without cost. Most web apps don't need this kind of scalability, so the development tradeoffs (like the chance of datastore operations failing, or the inability to wrap transactions around arbitrary sets of data operations) may be too much trouble. AppEngine isn't for all web apps, and many web apps would be very painful to shoehorn onto AppEngine. Still, if you want to build your app so it scales like Google's own apps scale, AppEngine can help get you there.

richardw 17y ago
There seem to be a few cases where it's far more than 2 or 4 times as long. I've found deleting takes ages - a couple hundred items can take a minute of "CPU" time. Discussions on the forum mirror that. I think it's great for many individual users doing tiny operations that don't interact with others, which my use case is. But you will be surprised by some of the performance characteristics. See this example: http://gaejava.appspot.com/ http://gaejava.appspot.com/
jbellis 17y ago
> You shouldn't care if a single hit on an AppEngine app takes 2 or 4 times as long as a single hit on your dedicated sever Actually, you should. Latency matters. Google knows this. http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-pag.html http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-...

stevejohnson 17y ago

As someone who does a lot of work in App Engine, my only gripe at the moment is that you can't delete an app once you create it. It exists forever.

bemmu 17y ago
I've started naming my App Engine apps bemmu1, bemmu2... so that if I decide to discontinue an app later, I can just reuse one without having an old name still attached to it. It doesn't really matter as the name would not usually be visible to a user.
- stevejohnson 17y ago
  I am more concerned about the 13(?)-app limit.
  - nickjohnson 17y ago
    10, but we can increase it if you ask.
    - mshafrir 17y ago
      Who would we contact about an increase?
babyshake 17y ago
You can always just empty your app.yaml or edit your code to return an empty page...
- stevejohnson 17y ago
  But the app is still stuck in your list.

damagednoob 17y ago

I question the benchmarks that are claimed for a single server. 10 million hits per day? Stackoverflow is just approaching 1 million hits and they've just recently gone to 2 web servers. Never mind the fact that the DB is also on a different server. The fact is that my argument makes as much sense as author's does. It all depends on what your server is doing.

BarsMonster 17y ago
The idea of GAE: we do care about scaling instead of you. What I prefer to think: write proper code, and you will never need a cluster (probably not for all cases). There are just 6.5billions people on the earth, so the maximum traffic is limited anyway.
- babyshake 17y ago
  App Engine thinks about a lot of thinks for you, besides scaling, and the roadmap suggests that it's going to continue to go into Amazon's territory, such as by hosting large static files. I'm still holding out on built-in full text search, but recent releases like a task queue and an XMPP client are nice additions.

bemmu 17y ago

The issue is not with GAE, but his code. It may look simple, but actually it is not using the data store as one should. Putting a single entity repeatedly does not scale, this is well documented. In the case of the example, a sharded counter is needed: http://code.google.com/appengine/articles/sharding_counters.html http://code.google.com/appengine/articles/sharding_counters....

BarsMonster 17y ago
Yes I've seen it. But it clearly shows some of the problems existing with GAE. It is possible to avoid them, as well as most of the rest, but we cannot deny the fact that there is a problem. Also, there are read-only tests which are also not amazing.
- Confusion 17y ago
  But it clearly shows some of the problems existing with GAE No it doesn't show that, because what we're discussing here is is not a 'problem'. The GAE datastore behaves this way by design. It may mean that some developers will experience problems, because they are not used to a non-relational database, but that only means they have problems. It doesn't mean that GAE has problems, unless you wrongly suppose, as you seem to do, that any developer should be able to use the GAE datastore as his relational-database-intuition tells him to.

thetrumanshow 17y ago

A tale of two projects: One one project (RoR), I have a BIG-IP load balancer in front of 4 dedicated servers, one of which is a db. On another project, I am running a straight Python app on App Engine. Guess which one I've had to wake up in the middle of the night to fix on occasion...

sanswork 17y ago
The one where you haven't outsourced the server support? Thats not a win for GAE so much as it is for outsourcing your server support.
- thetrumanshow 17y ago
  Oh, I see. Then, guess which one doesn't require me to seek out and contract a firm to handle my admin for me?
  - sanswork 17y ago
    The self managed RoR one. For the GAE one you sought out someone to host and manage your servers for you and contracted Google to do so.
    - thetrumanshow 17y ago
      Well, technically, both have some level of management which is bundled with the services. Ex: I don't have to literally put out fires if one breaks out in the server room. App Engine's management service by contrast is very tightly bundled to the hosting services... so tightly in fact that the cost of the management service they provide is exactly proportional to the cost of the resources I consume. It's a great deal. But we are getting off into the weeds here. App Engine simplifies server admin for me. I have never had to personally 'bounce' anything for any reason. I don't worry about running out of disk space. I don't have to worry about sweeping out the sessions (on disk or db). I don't have to setup database replication. I don't have to configure rolling archive tables to improve the speed of access to the most commonly accessed data on a large table. Being a solo operation, App Engine is ideal.

kljensen 17y ago

Clearly GAE does not "suck". We've used it a lot, e.g. [1]. The principal advantages are: - No sys admin. You can just focus on your app. - The datastore (BigTable) is slick. Write and read times are independent of how much shizzle you stick in there. - They're constantly making it better. E.g. the free quotas got more generous after a few months; and the new built in cron and off-line processing (taskqueue) support enables more complex apps. Clearly not for everybody. We love it. Does not suck. [1] http://news.priorsmart.com/ http://news.priorsmart.com/

gfodor 17y ago

In related news, I am getting CapabilityDisabledExceptions on my AppEngine site, with no warning or explanation. Edit: Yup, AppEngine is hosed! http://code.google.com/status/appengine/detail/datastore/2009/09/22#ae-trust-detail-datastore-put-error_rate http://code.google.com/status/appengine/detail/datastore/200...

gfodor 17y ago
Ah, its scheduled maintenence. Would have been good if they put that somewhere on the status page!
- nwinter 17y ago
  They recommend that you subscribe to their downtime-notify group. They post well in advance of scheduled maintenances, and have recently put up a schedule of all such maintenances through the end of the year. It's easy to miss the "you should subscribe here" info though.

jaspertheghost 17y ago

It's about time. Google AppEngine (Map Reduce, GFS, etc) has always lacked behind the Dynamo architecture in terms of winning developer mind share and specing the right features. The inherent problem with Google App Engine is it's not backwards compatible with existing system.

tybris 17y ago
By Dynamo, do you mean Amazon's service oriented architecture?

onreact-com 17y ago

Any headline like "x sucks", "x is bull####" or "x is dead" should be changed to "x critique" to establish some civility of discussion. This type of "pulling a Calacanis" headline is sheer link bait and rarely meant to stir an honest discussion.

scrame 17y ago
Agreed, along with "Did X just Y?" which is usually just speculative linkbait.

tybris 17y ago

I don't know why I would use an application platform that doesn't let me do anything, but I found it to be very useful as a reverse proxy.