Why Google AppEngine sucks

http://3.14.by/en/read/why-google-appengine-sucks

by gasull • 17 years ago

48 46 17 years ago

3.14.by

blasdel• 17 years 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.

th0ma52• 17 years 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.

BarsMonster5• 17 years 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.

ntoshev• 17 years 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.

BarsMonster5• 17 years 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• 17 years 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• 17 years ago

It would be nice if the article reflected that sentiment.

dchest• 17 years ago

The same article in Russian (click "RU") has the following title: "Should you use Google AppEngine?". The author has been lost in translation.

BarsMonster5• 17 years 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").

adrinavarro• 17 years 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• 17 years ago

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

DocSavage• 17 years ago

This just came out today:

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.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• 17 years 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• 17 years 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/

jbellis• 17 years 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-...

stevejohnson3• 17 years 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.

bemmu2• 17 years 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.

stevejohnson3• 17 years ago

I am more concerned about the 13(?)-app limit.

babyshake2• 17 years ago

You can always just empty your app.yaml or edit your code to return an empty page...

stevejohnson3• 17 years ago

But the app is still stuck in your list.

damagednoob• 17 years 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.

BarsMonster5• 17 years 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.

babyshake2• 17 years 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.

bemmu2• 17 years 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....

BarsMonster5• 17 years 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• 17 years 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.

thetrumanshow3• 17 years 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...

sanswork2• 17 years 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.

thetrumanshow3• 17 years 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?

kljensen• 17 years 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/

gfodor2• 17 years 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/200...

gfodor2• 17 years ago

Ah, its scheduled maintenence. Would have been good if they put that somewhere on the status page!

nwinter• 17 years 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• 17 years 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.

tybris2• 17 years ago

By Dynamo, do you mean Amazon's service oriented architecture?

onreact-com• 17 years 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• 17 years ago

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

tybris2• 17 years 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.

Why Google AppEngine sucks

Related Stories