First, App Engine will really only run things that are written for App Engine. If you have a Python web application, there's a good likelihood that it won't run on App Engine because it does things that App Engine doesn't (like relational database stuff or cron jobs or whatnot). Enterprise applications are things already written.
Second, enterprise applications are usually things that don't need to support millions of users so much as they need to have features. You're not serving like Digg or Google so much as doing non-real-time data processing. So, App Engine's infiniscale thing isn't as important as a relational database's ability to have triggers.
Third, App Engine doesn't have an SLA. That's a harsh sell for enterprise stuff. It doesn't even have a way to make a backup of the database in a dump file. That makes it an absolute no-go.
Fourth, App Engine's low cost usually isn't a concern on the enterprise level (even if it should be).
App Engine is a cool service, but whether it will become important is yet to be seen. If you're running a small site (say, 1,000,000 pageviews per month), you aren't going to have trouble scaling a MySQL/PostgreSQL database and application. You'll normally be showing one pageview per second at that rate. So, it's just as easy to go with Slicehost or Amazon. And using Amazon or Slicehost or the like has advantages - you get to use any software you find useful, you can have relational databases, etc. So, for small sites, App Engine's scaling capabilities aren't so important.
For larger sites, you just can't deal without a backup strategy, SLA, and cron jobs. It's too limiting. Plus, when you're a big site, you can hire people to deal with scaling issues.
So, it misses a little on both sides. I really want to love it, but there are just some gaps in the offering that are really important. I don't think Google needs to worry about the low side since they can't practically offer things like JOINs off their architecture, but on the high side, they need to offer data dumps and cron jobs and a little more information about the data integrity in the system (how many copies, how fast is it replicated, etc.)
If you're running a small site (say, 1,000,000 pageviews per month), you aren't going to have trouble scaling a MySQL/PostgreSQL database and application. You'll normally be showing one pageview per second at that rate. So, it's just as easy to go with Slicehost or Amazon.
It is significantly easier to go with App Engine, though. There's a sizable group of people who don't want to deal with all the messy details of SliceHost or EC2. When you consider that all they really want to do is host a web application and have it scale, requiring them to start with a bare metal VM is total overkill.
I'd disagree. App Engine places huge restrictions on what you can do. With a bare VM, I can install a database, webserver and go to town. With App Engine, I have to deal with all of the small quirks of their data store.
Examples:
You are doing something ___location-based and what to find things within 10 miles of a ___location. With SQL, you can do a crude bounding box query if it doesn't have to be that accurate. You can even do better geometric queries with PostGIS. With App Engine, you can't even do a bounding box query. Inequality queries can only be on one field at a time. Beyond the ___location example, you can't say get me the items where comment_count > 5 and author_karma > 10.
You can't do joins and so you have to denormalize a lot of data that will perform fine as normalized data.
There is no OR operator at all.
Saying that it allows you to ignore the messy details is like saying that you can avoid having to get egg on your fingers making an omelet if you create a machine that can automatically create food. It is not easier to go with App Engine for the majority of applications which would benefit from simple things that App Engine doesn't support.
It is far easier to scale something written for App Engine. That's the payoff. Even if you have to port away from App Engine, you've still created a data storage strategy that doesn't require joins; you've still moved a lot of the data processing out of the database and into Python manually; you've still made it so that you aren't using any advanced queries. App Engine forces you to write applications in a way that scales. App Engine doesn't allow you to do any of the operations that make programming quick to do. It's a trade-off and depending on whether your application needs it, it can be worthwhile or not.
You are talking past each other. neilc pointed out that it is easier to go with App Engine, which is probably true. Your criticisms are that App Engine does not have as many features, which is also true. App Engine isn't aimed at "enterprise" so much as it's aimed at "people who don't want to bother setting up a VPS."
Here's one obvious use case: social apps. Most apps on facebook, myspace, etc don't really require perfectly normalized data, most of the stuff is just for fun, or games to generate ad revenue etc. Plus, you don't have to worry much about the scalability issue other than making your queries run fast, once it's on app engine, a million myspace users hitting your app won't even make you worry.
I've got my own colocation facility with virtual machines and the like as well as an amazon ec2 account with several vms, but I still make use of google app engine any time I want to write a facebook/orkut/myspace app.
It is significantly easier to go with App Engine, though.
For values of easier which include:
1) Learn to program in Python.
2) Forget everything you know about databases.
3) Lose the accumulated value of all reference work on the Internet on, e.g., "How do I send an email to someone 3 days after they sign up for my free trial?"
The format doesn't matter. The fact that there is no backup mechanism matters. App Engine does have some built-in redundancy, but as we've seen in some high-profile incidents, backups are a necessity. App Engine provides no facility to create backups.
First, App Engine will really only run things that are written for App Engine. If you have a Python web application, there's a good likelihood that it won't run on App Engine because it does things that App Engine doesn't (like relational database stuff or cron jobs or whatnot). Enterprise applications are things already written.
Second, enterprise applications are usually things that don't need to support millions of users so much as they need to have features. You're not serving like Digg or Google so much as doing non-real-time data processing. So, App Engine's infiniscale thing isn't as important as a relational database's ability to have triggers.
Third, App Engine doesn't have an SLA. That's a harsh sell for enterprise stuff. It doesn't even have a way to make a backup of the database in a dump file. That makes it an absolute no-go.
Fourth, App Engine's low cost usually isn't a concern on the enterprise level (even if it should be).
App Engine is a cool service, but whether it will become important is yet to be seen. If you're running a small site (say, 1,000,000 pageviews per month), you aren't going to have trouble scaling a MySQL/PostgreSQL database and application. You'll normally be showing one pageview per second at that rate. So, it's just as easy to go with Slicehost or Amazon. And using Amazon or Slicehost or the like has advantages - you get to use any software you find useful, you can have relational databases, etc. So, for small sites, App Engine's scaling capabilities aren't so important.
For larger sites, you just can't deal without a backup strategy, SLA, and cron jobs. It's too limiting. Plus, when you're a big site, you can hire people to deal with scaling issues.
So, it misses a little on both sides. I really want to love it, but there are just some gaps in the offering that are really important. I don't think Google needs to worry about the low side since they can't practically offer things like JOINs off their architecture, but on the high side, they need to offer data dumps and cron jobs and a little more information about the data integrity in the system (how many copies, how fast is it replicated, etc.)