
Why Google AppEngine sucks - gasull
http://3.14.by/en/read/why-google-appengine-sucks
======
boggles
_"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.

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

~~~
BarsMonster
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
So western tastes _prefer_ trolling?

~~~
ilyak
Nope, it's russian tastes that would make a huge trollfest of such a title.

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

~~~
ntoshev
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
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).

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

~~~
jbellis
> 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-...](http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-
pag.html)

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

------
stevejohnson
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
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
I am more concerned about the 13(?)-app limit.

~~~
nickjohnson
10, but we can increase it if you ask.

~~~
mshafrir
Who would we contact about an increase?

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

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

~~~
DocSavage
This just came out today:

[http://googleappengine.blogspot.com/2009/09/agile-
paddling-w...](http://googleappengine.blogspot.com/2009/09/agile-paddling-
with-app-engine-lessons.html)

"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...](http://files.meetup.com/1135107/BuddyPoke_AppEngine_Stats.pdf)

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

------
bemmu
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....](http://code.google.com/appengine/articles/sharding_counters.html)

~~~
BarsMonster
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
_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
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
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
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
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
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.

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

------
gfodor
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...](http://code.google.com/status/appengine/detail/datastore/2009/09/22#ae-
trust-detail-datastore-put-error_rate)

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

~~~
nwinter
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
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
By Dynamo, do you mean Amazon's service oriented architecture?

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

------
onreact-com
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
Agreed, along with "Did X just Y?" which is usually just speculative linkbait.

