There are other advantages that probably encouraged Google's choice of Python. The most popular implementations are open source. and the language's creator, Guido van Rossum, works there. This must have made it much simpler for the company to create the slightly crippled version of Python that runs on the app server. This sandbox forbids some potentially dangerous operations such as writing to the file system, a feature that could pretty much prevent building Flickr-like upload services unless you feel like storing these big blocks of data in the database. Your code isn't allowed to spawn subthreads, and it better be efficient because it looks like App Engine will kill any thread that takes too long. This is probably necessary given the endless loops that will be created by newbies, but it pretty much means that App Engine is really just for front ends to databases that don't do much independent thinking or computation.

The Bottom Line Google App Engine preview release Google, google.com/appengine Preview   Cost: The beta program is free but closed to new members. Applications are limited to daily quotas such as 2,000 e-mail messages, 200 million CPU megacycles, and 2.5 million data store calls. The documentation suggests that users will be able to spend money to expand the quotas. Platforms: Any Python 2.5 Web application that operates in a sandbox that excludes actions such as writing to the file system. Google has integrated several standard Web frameworks to simplify the development process. Bottom Line: Google App Engine hides the grime of deploying a scalable application to a number of servers. The limitations on the sandbox make this "cloud" best for dynamic Web sites that act as a relatively thin layer of business logic sitting on top of a data store. Google's Python/Django framework makes developing simple applications quick, and the database structure encourages scalable design by excluding joins. On the downside, there's not much support for AJAX, porting some applications will require rethinking the database schema, and your coders better like Python, which is currently the only option. About our Reviews and Scoring Methodology

Smells like SQL
It's probably best to think of the system as a thin layer of business logic in front of a simple database, the kind that DBAs like to call a "data store" to emphasize the point that you can't do most of the complicated things that Oracle allows. The database is nicely integrated with Python but it only offers the kind of basic search and store functions that developers will need to squirrel away their user's information. You set up the data objects in Python, hit the save method, and the data disappears into the cloud where all of the instances of the application can find it. The language is pretty close to SQL, but it comes with a slightly different syntax, which means that you won't be able to use any of the millions of tools that sort of speak SQL to generate reports or produce graphs. Furthermore, the data store API doesn't include old-fashioned joins, an omission that will break some of the code written for traditional databases. The simplicity is nice, but there's a reason why everyone ends up using standard databases for the core of their projects.

So there is a certain amount of lock-in hiding in the API. Porting your application to something like MySQL won't be automatic but I doubt it would be hard at all. Going in the other direction, though, could be both healthy and annoying. Because there's no way to join tables, you're effectively forced to denormalize your tables. Most Web developers end up doing this eventually to help things scale, so I guess it makes sense to start out that way even if it seems a bit messy.

There are omissions. The documentation mentions Web services and AJAX (Asynchronous JavaScript and XML), but there's very little support for them out of the box. Perhaps there will be some grand catalog encouraging mashups in the future. It would also be nice to offer some basic templates for data structures so that most of the applications could begin with the same standard formats for dates, locations, and other things. Currently you don't get much beside the simple Python application framework with a bit of MVC (model-view-controller).

Nor are there many of the tools that might be essential. The samples and the tools all run through the command line, probably the preference of the developing team. I can see that developers might want more sophisticated tools for profiling the code and tracking every click. Google suggests profiling by dumping the profile information between <pre> tags in an HTML document. Using <table> tags would probably confuse the command line jockeys.

Sky's the limit
The plan is to charge when applications exceed some limits, a perfectly fair plan but one that makes me a bit nervous after years of basic pricing for servers. The terms and conditions suggest that you only get "200 million megacycles of CPU per day." You can see a snapshot of resource consumption, but this seems like an especially squirrelly metric that could be skewed in odd ways by factors beyond the developer's control. If you send a weird query to the database, it may burn cash in a way that you didn't anticipate. One of the biggest headaches for Java programmers comes when an instance of an application on one server starts asking for data that happens to be sitting on another server. Inter-server communication can slow fast boxes to a crawl, and entity locking could get scary if two users start nibbling at the same bytes at the same time.