I'm using app engine for all my new app idea and here's why.
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.
Possible cons.
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:)
>3. I can build and test an app idea for free. If it gets traction it's already to be scaled.
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.
I've just launched LinkPeelr on App Engine: http://linkpeelr.appspot.com. It was seamless, quick and easy, and the app is getting a bit of traction already. I am estimating that with free quota I can support about 10,000 active users. LinkPeelr is a dead simple web, but this should give you some idea of how far you can scale without spending a cent.
For more on why this makes sense, see:
"PaaS as a satisfying and success-ready hobbyist platform" (with Google App Engine as the primary example)
http://stage.vambenepe.com/archives/1014
Apparently it's not only for hobbyists... it's the leading favorite amongst enterprise CIOs too, as seen in this Morgan Stanley survey which just came out last week: http://goo.gl/LcbS
Don't forget to use django-nonrel so that you can move apps b/w App Engine and any normal ISP supporting Django apps. You only need to change your database in settings.py! http://allbuttonspressed.com
Did they ever release any information about how popular App Engine is? I've always wondered how successful it's been and how many startups are willing to lock themselves into the Google Infastructure.
I don't know how this project is doing, but it may ease the worry about reliance on Google infrastructure if they can keep it going:
"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."
I am 110% locked into GAE with a start up in the legal services space. And I couldn't be happier. For needs that cannot be satisfied by GAE, our app spins EC2 instances up and down as required (from GAE).
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.
AppEngine is (especially) nice for hobby projects fitting into the free quota. Although the concept is generally great, for commercial use there are some frustrating restrictions, such as lack of support for naked domains, which nailed my decision to go with Tornado + MongoDB + <your-favorite-cloud-hosting>.
(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.)
On your last point, I found the exact oppisite with google app engine. I am using it to build an app that has integration with maps and docs and the infrastructure helps a lot to get the app to beta users quickly (it took me two weeks to get it to beta users. If I had not used app engine, I estimate that it would've taken atleast two months, maybe more).
I think one of the main advantages to GAE is the time to get a site up and running. There's zero server setup, installation, or management. This definitely helps you get out the door fast. You're right though in terms of data mining etc... I work for a keyword intelligence site that definitely couldn't run on app engine. We run on a Microsoft stack like stackoverlow and are extremely lean for what we do. However, if I were to start a web 2.0 type site where most of the value is created by users i.e. facebook, twitter, wikipidia, craigslist, or even stackoverflow, app engine would be the way to go.
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.)
I've twice tried (unsuccessfully) to use it for small projects. Last week I had to re-write an app to port it off the platform because it suddenly stopped being served correctly when accessed via my own domain name.
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 using it as the backend for my Windows app's sync. So far it's been great. Latency isn't that much of an issue because sync happens in the background, but users report it as very quick.
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.
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.
Possible cons. 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:)