I was really excited for App Engine when it came out. However, I don't think Google has realized its potential.

First, I want to comment on price. When it was introduced, I thought it would be cheaper than alternatives (like AWS, Softlayer, Linode, and the Rackspace Cloud). It doesn't look cheaper now.

They introduced "backend" processes today that look really pricy (http://code.google.com/appengine/docs/python/config/backends...). For 64cents, one gets 4.8GHz and 1024MB RAM for an instance that can do long running processes. For 68cents, Amazon is offering 20GHz and 7GB RAM - or 5GHz and 1.7GB RAM for 17cents. That's a huge price disparity. Google is billing with 15 minutes tacked onto the end of the usage and so it feels a lot more like AWS billing. If I'm spinning up a "backend", how is that different from spinning up an AWS instance for an hour? I can programmatically launch AWS instances and then shuffle work to them and then terminate them when they're done. Likewise, if I'm only sending work to the backend every 10 minutes, the instance will be always-on and so I'm not taking advantage of anything more advanced that would see me not being billed for the time I'm not using.

The move to instance hours over CPU used similarly means that I'm not taking advantage of advanced multi-tenancy tools Google might have created, but rather am using something that's basically Heroku. Google is charging 5cents per hour for a reserved instance - basically a Dyno at Heroku. If you're doing pay-as-you-go, you're paying 8cents per hour. At 8cents per hour, you could nearly get a full 1.7GB instance at AWS. In that 1.7GB, you could probably fit a dozen or more instances of your app. Heroku makes its living off the fact that a Dyno is probably taking up 100MB of RAM and some CPU and that 5cents/hour is a lot to pay for that. Now, Heroku is making up for that because they make it really easy to deploy and forget about server stuff. While Google is also making it so that you don't have to deal with the server stuff, there's a part of me that says the situation is very different - that I could take most generic Rails apps and put them on Heroku (as long as they don't need filesystem access), but I couldn't take most generic Django apps and put them on App Engine without modification. Not only that, but Heroku throws in bandwidth for free.

It just seems like this area is heating up and Google hasn't stepped up. Heroku is very well-established. VMWare has started to enter the fray, there have been Django ones that I've seen, and even the Play Framework has one. With the pricing changes, Google is certainly not cheaper and doesn't have the flexibility that most of them have to run applications not coded specifically for it.

Second, there's the issue of migration. I can't really go between App Engine and something else easily. Django non-rel exists, but it's been over 3 years since App Engine's launch and it doesn't look like migration is going to be trivial. So, unlike Google's growing number of competitors, there's a lot more lock-in there. If Google decided to discontinue the product, it would be painful to move. If they started charging more money, it would be hard for me to move to another provider. I guess I thought that Django might have done more work to make App Engine supported (even without joins and such) in a way that one could move on/off App Engine with the caveat of not using joins, the filesystem, etc. Heck, I even remember reading about Brad Fitzpatrick working on an App Engine-like package so that App Engine apps could be run on one's own servers (with a NoSQL store and such) if one wanted/needed to migrate away, but it hasn't made much news lately and might have been semi-abandoned. App Engine support didn't go as mainstream as I thought it might and that means that my expectations around migration aren't quite as positive.

Third, I guess I'm disappointed at the amount of attention paid to it. To me, it looks like this is a cool project that Google thinks is cool, but that they haven't found a way to monetize it. Like, AWS is a huge thing for Amazon. App Engine seems like something they want to dedicate some resources to, but not something they're too worried about progressing quickly on or really getting a foothold in the market. It's hard to commit to it when there are things it doesn't do (or doesn't do well) and it isn't clear if they ever want to do it well. For example, geo-querying isn't impossible, but isn't the easiest thing on App Engine. While Google might be forcing you to use a technique that would work even if you had billions of users, bounding box (and other) queries can be a much easier technique. Yes, they've trotted out SQL again and it might happen, but you're putting yourself in a situation where the product feels incomplete in some ways with Google not feeling too pressed to make it complete fast. I know that's not the best argument - the word "feel" should give that away - and that one can say that other providers can't do everything either. However, it's a lot less concerning if Heroku doesn't do something because I can more easily leave Heroku and host it myself.

--

I guess I felt that my implicit feelings on App Engine were something like, "Hey hackers! You should totally rewrite your apps for our Google systems that are a lot more efficient than other systems. Yeah, there are some annoying restrictions that you'll have to get used to and are totally a pain for some things. Still, out service is cheap for loads of usage and really cheap even after that so you're spending a little programmer time for no-hassle-scaling and cheaper hosting than anything you can get!"

However, they've consistently lowered the free usage tier to being a fraction of what it once was, they're now charging a ton more with their instance-hour model compared to the old CPU based model, a bit of the reliability/scaling sheen has worn off as it's had problems, other competitors have been aggressively entering this space, and you still have to alter your apps specifically for their architecture. I'm not saying that App Engine doesn't have value, just that it feels very different.