Is Google App Engine Ready for Prime Time?(sachinrekhi.com)
sachinrekhi.com
Is Google App Engine Ready for Prime Time?
http://www.sachinrekhi.com/blog/2009/01/02/is-google-app-engine-ready
18 comments
Two weeks ago, my client’s datastore indexes became corrupted. The failure was demonstrably AppEngine's. Attempts to manually rebuild indexes failed. The AppEngine team worked for several days to resolve the problem, which we appreciated. But such failures are disheartening when you’re busy signing up paid customers.
I suppose the term “beta” is so overused that it has nearly lost its meaning. Sometimes, however, it still means “warning, ye who enter here.”
--
I've also written some high-level thoughts about the "big three" cloud services on my blog:
http://davepeck.org/2008/11/30/the-clouds-spectrum/
http://davepeck.org/2008/12/03/the-clouds-dark-lining/
I suppose the term “beta” is so overused that it has nearly lost its meaning. Sometimes, however, it still means “warning, ye who enter here.”
--
I've also written some high-level thoughts about the "big three" cloud services on my blog:
http://davepeck.org/2008/11/30/the-clouds-spectrum/
http://davepeck.org/2008/12/03/the-clouds-dark-lining/
Do you have any pointers to what was wrong and how it was resolved?
Unfortunately, the issue still lurks.
Basically, some combination of puts to one of our models would cause queries to return inconsistent results. For example, the query:
SELECT * FROM MyModel WHERE property=True
would return N results, but
SELECT * FROM MyModel WHERE property=True ORDER BY foo
would return far fewer than N results.
It appears that _something_ we were doing exercised an AppEngine bug that caused the indexes to get corrupted. (Note that this would happen even from AppEngine's data viewer -- which is to say, we got N by paging through ALL results, not just one fetched batch.)
We worked with Google but designing a simple repro case proved difficult -- the corruption happened only under high load, and only on one of our models.
Trial and error showed us that if we manually fetched and re-put() the "broken" rows in our table (aka the ones that didn't show up when we used ORDER BY,) the indexes would right themselves. So I wrote a bit of code to do this, and started running a cron job on a local box to invoke that code regularly. Lame, but only temporary.
Last time we exchanged mail with the AppEngine team, they told us they were aware that this was a bug on their end and were working on a fix. However, to my knowledge, they're still working on it...
Basically, some combination of puts to one of our models would cause queries to return inconsistent results. For example, the query:
SELECT * FROM MyModel WHERE property=True
would return N results, but
SELECT * FROM MyModel WHERE property=True ORDER BY foo
would return far fewer than N results.
It appears that _something_ we were doing exercised an AppEngine bug that caused the indexes to get corrupted. (Note that this would happen even from AppEngine's data viewer -- which is to say, we got N by paging through ALL results, not just one fetched batch.)
We worked with Google but designing a simple repro case proved difficult -- the corruption happened only under high load, and only on one of our models.
Trial and error showed us that if we manually fetched and re-put() the "broken" rows in our table (aka the ones that didn't show up when we used ORDER BY,) the indexes would right themselves. So I wrote a bit of code to do this, and started running a cron job on a local box to invoke that code regularly. Lame, but only temporary.
Last time we exchanged mail with the AppEngine team, they told us they were aware that this was a bug on their end and were working on a fix. However, to my knowledge, they're still working on it...
Good Lord thats scary sounding.
I believe the app engine datastore has been stated as being built upon bigtable. I suppose the index creation is "newer" code than the core of bigtable, but I'd like to hope that the Google bigtable code is bugfree at this point...
I believe the app engine datastore has been stated as being built upon bigtable. I suppose the index creation is "newer" code than the core of bigtable, but I'd like to hope that the Google bigtable code is bugfree at this point...
Yup, I filed issue #901:
http://code.google.com/p/googleappengine/issues/detail?id=90...
Seems like a serious bug, but I haven't seen any updates as yet.
http://code.google.com/p/googleappengine/issues/detail?id=90...
Seems like a serious bug, but I haven't seen any updates as yet.
I got the impression we weren't the only ones. Good to see a bug filed, will star it!
Were you ever able to find an isolated repro case?
Were you ever able to find an isolated repro case?
I recommend staying off of GAE. I was prepared for some bumps, but the failures that I've experienced have, to put it bluntly, made me lose a great deal of confidence in Google in general.
Even if it were more stable, I would still be migrating my company site off of it. The feeling I have now is one of helplessness - my site is going to arbitrarily go down and it'll be Google's fault and there's not a thing I can do about it. It takes me back to the emotions I had in the bad old days when I dealt with Microsoft software in a professional capacity.
Even if it were more stable, I would still be migrating my company site off of it. The feeling I have now is one of helplessness - my site is going to arbitrarily go down and it'll be Google's fault and there's not a thing I can do about it. It takes me back to the emotions I had in the bad old days when I dealt with Microsoft software in a professional capacity.
Please star issue 313 to encourage the GAE team to implement distributed transactions:
http://code.google.com/p/googleappengine/issues/detail?id=31...
BTW, I'm currently working on a GAE app: http://readmytweets.com.
http://code.google.com/p/googleappengine/issues/detail?id=31...
BTW, I'm currently working on a GAE app: http://readmytweets.com.
From my own limited experimentation I came to same conclusion as the author. I think that the platform is nice for toy projects because you do get a fair amount of resources for free. However, there are too many limitations for even a serious personal project. This may change once we finally get official pricing.
Pricing's more or less been announced though I guess it's still not "official" yet:
* $0.10 - $0.12 per CPU core-hour
* $0.15 - $0.18 per GB-month of storage
* $0.11 - $0.13 per GB outgoing bandwidth
* $0.09 - $0.11 per GB incoming bandwidth
http://googleappengine.blogspot.com/2008/05/announcing-open-...
It's slightly more expensive than Amazon.
* $0.10 - $0.12 per CPU core-hour
* $0.15 - $0.18 per GB-month of storage
* $0.11 - $0.13 per GB outgoing bandwidth
* $0.09 - $0.11 per GB incoming bandwidth
http://googleappengine.blogspot.com/2008/05/announcing-open-...
It's slightly more expensive than Amazon.
Not sure if it's more expensive, even if you ignore the free quota. Amazon charges you $0.10 per instance-hour, not cpu-hour like Google (so you only pay while you consume CPU). Also, you should probably compare the storage price not to S3/EBS, but to Simple DB (you still pay for CPU time spent in the datastore, though).
My problem with the pricing is not that Google hasn't indicated what the pricing will be like, but that if you need more resources there is no other option except hope that Google will be nice to you and up your quotas.
Anyone found a good tutorial for pointing mydomain.com to myapp.appspot.com ?
The process is ridiculous and horribly undocumented.
Also, custom domains can't have SSL. That's a deal killer right there for most startup projects.
I am using GAE for some basic pages. Where I would make a static page, I'm running Django. The deployment process is a breeze, and any of the pages can scale to be a proper app. I'll probably move http://kirigin.com there soon.
The process is ridiculous and horribly undocumented.
Also, custom domains can't have SSL. That's a deal killer right there for most startup projects.
I am using GAE for some basic pages. Where I would make a static page, I'm running Django. The deployment process is a breeze, and any of the pages can scale to be a proper app. I'll probably move http://kirigin.com there soon.
You are right, it is a pretty confusing process. Here is the best docs I could find on the topic. You basically setup your domain first with Google Apps for your domain. Then you link the Google Apps for your domain account with your Google App Engine project. The additional issue is that you can't map naked domains (http://domain.com) to Google App Engine directly. Instead you have to do that within your DNS provider (I set it up in GoDaddy).
http://knol.google.com/k/larry-h/google-apps-discussion-grou...
http://knol.google.com/k/larry-h/google-apps-discussion-grou...
Good to see you blogging Sachin. I've got a whole Google Reader folder for fellow YCers.
Examples:
The 1MB file upload limit. It's not that I want to have users uploading 500MB tars or something, but I don't want to put a message in my app saying, "please resize you photo to be less than 1MB before uploading where we'll probably alter the photo again."
They've indicated that you'll be able to purchase more storage and bandwidth which is great, but noticeably absent was the ability to send more than the 2,000 email limit (http://googleappengine.blogspot.com/2008/12/system-status-da...). The problem might not be that I want to send more than 2,000 emails in a single day. The problem is that these quotas are rolling windows. Plus, the whole point is that AppEngine scales without me having to do anything. If it doesn't accommodate a decent sized social app, I might as well just put something on Slicehost or EC2 since at that low a usage rate, scaling isn't that hard.
There's no map/reduce or cron-like jobs. The datastore in AppEngine acts as a bit of a straight-jacket to ensure you don't do operations that don't scale. However, without map/reduce and cron jobs, it can mean that you just can't do certain things. And yes, I know that you could fake it by running another server, making an HTTP request to AppEngine and cutting up a process that might take a minute into chunks that AppEngine would execute, but that's just silly. The whole point of AppEngine is not having to deal with your own server and having an integrated environment that just works.
If the purpose of AppEngine is for developers not to worry about deployment and scaling, then it just fails because of some of the limitations. AppEngine doesn't scale. Maybe that's just a matter of the quotas being removed/being able to pay for more, but as of right now it doesn't scale at all. And it doesn't seem to be an amazingly high priority at Google. Software development takes time, but it's been a while since they said developers would be able to buy more and it hasn't come - beyond the recent blog posting I linked to showing some screen shots.
AppEngine could be a wonderful platform to develop on, but not until some of these problems get fixed.