1. It's great for a one man show. Building an app takes a lot of time. I don't need to speed my time being a sysadmin. I want to spend it coding. I've used EC2 and a lot of my time was just spent tweaking and getting an instance working and making sure you don't lose your data.
2. The api's are great. I have instant access to memcache, mail, image and task queue apis, zero configuration.
3. I can build and test an app idea for free. If it gets traction it's already to be scaled.
4. I like Python. I used to be a php guy but after working with python my tastes have changed.
5. It's fast (most of the time). I do every once in awhile experience latency but no deal breakers.
1. Technology lock in. Lets face it though, you're locked in with whatever stack you choose. If you get successful who cares, then you can hire so one to re-code your app if you desire.
2. Python and Java only, yep I can see this being a con. I had to learn Python to use app engine, which I don't think is a bad thing.
3. Terms and conditions. You are bound to their T's and C's
I'm sure there are more cons but in my situation I want to build an app quickly and it out the door. If it takes off I'm ready to scale and make some money:)
Here's a good article on modeling relationships.
I think this is huge reason to go with GAE. For instance I'm trying to launch a service to allow people to see deleted reddit comments (unedditreddit.com). It's a dinky little idea and I have no idea if it will get traction or not, but if it does get traction it will have to bear the load of the massive reddit userbase.
I could deal with this by trying to solve the scaling issue on my own from the beginning, making implementation take a lot longer and more complex. Or I could do a simple implementation not solve scaling, and try to panic patch as the site starts to break under pressure. Or I could do a GAE implementation and have the best of both world.
"AppScale is a platform that allows users to deploy and host their own Google App Engine applications. It executes automatically over Amazon EC2 and Eucalyptus as well as Xen and KVM. It has been developed and is maintained by the RACELab at UC Santa Barbara. It supports both the Python and Java Google App Engine platforms."
For me, the numerous benefits of the platform outweigh the lock-in risk by a large margin.
First, a startup's advantage is that you're small. You don't have to worry about serving 100 million users. That means you can make your life a bit easier as you grow. You can use a relational database while you're small, add memcached as you grow, denormalize, etc. AppEngine makes you develop your application to your end point in some ways. You can't use the techniques that get you out the door fast with a high-quality product. Rather, you have to over-engineer your product to scale to a number of users you'll likely never have. Take Stack Overflow as an example. They're a really successful service and they're running on 5 servers and a SQL database. Now, I'm sure they've done caching and a bit of denormalization, but the key is that they could launch without doing that and as they got more and more users they could add that in.
Second, Google's infrastructure doesn't really have capabilities for some of the cool things. For example, geolocation is a pain (http://code.google.com/appengine/articles/geosearch.html). MapReduce doesn't really exist. I mean, there are ways to deal with your data. The key to MapReduce is its distributed nature - that portions of the data can be computed on different boxes at the same time and then returned. This limits your ability to do the kind of warehouse data processing that can give you really cool results. And AppEngine is meant for web apps, not things trying to compute stuff like Google does. Google is addressing lots of things. You can now get incoming email. They introduced the task queue. But you're beholden to a third party for a lot of things. Part of being a startup is trying to be beholden to yourself and changing course quickly as you see something important. AppEngine might limit you there depending on what you're looking to do. Of course, it might also help.
Third, you're locked into Google's cost structure. It isn't expensive or unfair. However, it is likely to be more expensive than owning your own boxes if you're large and you have the issue that Google may not lower prices in step with competitors. Amazon has been aggressively cutting prices, Linode has been upping RAM, etc. It's a lot harder to migrate away from App Engine.
Fourth, you're beholden to Google for your application's health. Google is a great company with wonderful engineers and AppEngine isn't abandoned at all. That said, they have had datastore problems that saw the time to get one entry from the datastore rise to 1.5 seconds or higher. Even after fixing the problem, it isn't the fastest option out there. Note, App Engine is made to be scalable and Fast Enough. It isn't tuned for pure speed. Basically, you have to start closer to the more difficult to build, highly-scalable architecture that you could be building as your site grows.
It's a cool product. The problem from my perspective is that there's little reason for me to engineer a site that scales to high levels if no one is going to use it. I don't know how many people will use a site until it's built. I have a better chance of people using my site if I can a) get it out quickly and b) add the features users want rather than the features that are easy with AppEngine. I'm not going to get all my users overnight. In the months it takes to get lots of users, I can optimize my code. Plus, if it takes off, I think it would be a bit weird to be beholden to a single vendor. Yes, there are open-source App Engine mostly compatible things out there and work arounds. Still, it's easier to move from Linode to Amazon or Slicehost to a physical server.
I've rambled a little too much, but it's half past midnight.
I haven't heard of any limitations on using custom domains for commercial use, cf. http://groups.google.com/group/google-appengine/browse_threa...
(For non-commercial use this limitation may be more acceptable, but if you are seriously launching a commercial service, you probably want to freely choose your domain.)
Another disadvantage is that you have a limited selection of programming languages. Plus, your infrastructure would be tied into google.
I'm working on an MMORPG for Android (http://developingthedream.blogspot.com/) and one of the obstacles I have is finding a cheap host.
That's what makes GAE so enticing. For small, to mid-size project you can really create something useful without any budget at all.
AWS, I find is too expensive for the starved programmers. (and horribly slow from my experience.)
Linode sounds ok. I guess to start off it wouldn't be too bad at $20 a month.
I'm a bit worried of scaling in a shared environment. My app would get much better performance on a dedicated box.
You're right though, it's really hard to tell how many users your app should support.
I actually plan to deploy on my HOME server.
Using a basic Time Warner Road Runner broadband account I get a slightly decent upload speed (1.76 MB UP/)
Sure it'll be a bit slow at first, but it'll be free and it'll help me gauge interest in the app.
(Plus if not many people are using it at once, it should be fast enough.)
Basically it stopped working, no error messages, no way to debug the problem.
I like the principle behind GAE and friends, but I keep going back to hosting things on my VPS. It works, and when/if it breaks I can surely fix it.
I'm keen to put a GWT front-end on it. I've tried that on a side project and it worked well. I do worry about the relative unpredictablility compared to just a plain box, but it's balanced with the fact that I really don't want to worry about operating system and web server level security or admin.