Is Google App Engine Ready for Prime Time?
sachinrekhi.com
sachinrekhi.com
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.
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:
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...
http://code.google.com/p/googleappengine/issues/detail?id=90...
Seems like a serious bug, but I haven't seen any updates as yet.
Were you ever able to find an isolated repro case?
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...
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.
http://code.google.com/p/googleappengine/issues/detail?id=31...
BTW, I'm currently working on a GAE app: http://readmytweets.com.
* $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.
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.
http://knol.google.com/k/larry-h/google-apps-discussion-grou...