Why Google AppEngine sucks(3.14.by)
3.14.by
Why Google AppEngine sucks
http://3.14.by/en/read/why-google-appengine-sucks
46 comments
The same article in Russian (click "RU") has the following title: "Should you use Google AppEngine?". The author has been lost in translation.
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").
So what we are left with is link baiting in english? no thanks... it doesn't need a title like that.
It would be nice if the article reflected that sentiment.
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.
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.
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.
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).
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.
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.
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.
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.
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.
> 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-...
Actually, you should. Latency matters. Google knows this. http://radar.oreilly.com/2009/06/bing-and-google-agree-slow-...
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/
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/
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.
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.
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.
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.
I am more concerned about the 13(?)-app limit.
You can always just empty your app.yaml or edit your code to return an empty page...
But the app is still stuck in your list.
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/
- 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/
Anyone care to share a real-life GAE performance figures non-free billable account on a long running application?
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).
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).
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....
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.
Also, there are read-only tests which are also not amazing.
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.
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.
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...
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...
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.
Oh, I see.
Then, guess which one doesn't require me to seek out and contract a firm to handle my admin for me?
Then, guess which one doesn't require me to seek out and contract a firm to handle my admin for me?
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.
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.
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.
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.
The fact is that my argument makes as much sense as author's does. It all depends on what your server is doing.
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.
There are just 6.5billions people on the earth, so the maximum traffic is limited anyway.
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.
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.
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...
Edit: Yup, AppEngine is hosed!
http://code.google.com/status/appengine/detail/datastore/200...
Ah, its scheduled maintenence. Would have been good if they put that somewhere on the status page!
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.
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.
By Dynamo, do you mean Amazon's service oriented architecture?
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.
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.
This type of "pulling a Calacanis" headline is sheer link bait and rarely meant to stir an honest discussion.
Agreed, along with "Did X just Y?" which is usually just speculative linkbait.
It would be nice if the title reflected that sentiment.