Google didn’t go the same way as Amazon with its AWS. The former offers a form of shared hosting (think “distributed WebFaction”), while the latter offers a virtualized environment (think “distributed SliceHost”). So basically we are talking about more high-level approach to web applications, which is easy even for novices. On the other hand AWS is more flexible and more enterprise-y.
In order to scale, you have to virtualize. In order to virtualize, some actions should be restricted. Google App Engine provides a sandbox on the language level. Only one language is supported at the moment: Python. And guess what? Django is everywhere! For virtualization reasons only the pure Python is supported and a subset of the Python standard library. You can bundle any pure Python modules with your application. Three third-party libraries are available out-of-the-box: Django 0.96.1, WebOb 0.9, and PyYAML 3.05. But fret not, you can bundle a framework of your choice with your application and run it too, even a custom version of Django — basically anything that supports WSGI. I suspect that other mature Python frameworks will be supported out-of-the-box eventually. Pylons and TG2 come immediately to mind.
Google uses Bigtable as the database backend. Bigtable is not a relational database, so it is not possible to use it with the Django ORM directly. At least not yet. So they provide their own ORM. It looks like … Django ORM with models and whatnot. It is possible to move the existing application to the new database with relatively minor edits provided that you didn’t do any esoteric implementation-dependent hacking in your application. Obviously with Django ORM gone, Django Admin is gone too as all model-based applications in django.contrib. Google App Engine provides its own application for administration, but I didn’t try it yet, so I cannot comment on its quality.
Everything looks simple, standard protocols are used if possible. For example, for distributed applications you have to support some kind of a message delivery system. Amazon does it with Amazon Simple Queue Service. Google uses email messages. Simple yet effective. If you want to connect directly and fetch a file or something, there is URL Fetch API — only http and https ports are supported. Again, simple yet suitable for many things — this is exactly how the internet is glued together.
Obviously it is not enough to write an application to host it properly. You should know where you can read local files, and how to serve static files. This stuff is usually done with web server-dependent configs. There is such config in Google App Engine done with YAML. Just like in Django URL paths are implemented with regular expressions. You can designate URLs for dynamic processing. You can define, which directories host static files, you can do it on per file basis too, and you specify how to treat uploaded files. It is possible to specify an expiration time, and set MIME types. Currently there is no way to control compression for static files. All in all you can do most of tweaking described in my article on performance tuning.
In real life when you use a database it is not enough to define your models. Most probably you need to set up indexes to speed up frequent queries. Again there is a YAML-based config for that. It can be generated automatically while you debug your application.
Speaking of debugging. The SDK contains the Dev Web Server very similar to what we use to debug Django locally. Additionally it can be used to upload your finished application to Google. BTW, there is no waiting list to download it — you can get it and try it now.
Presently this service is free, but there are some limitations: disk storage is up to 500M, both incoming and outgoing traffic is restricted to 10G per day each, up to 2000 emails per day, and up to 200 million megacycles of CPU per day. Up to 3 applications can be registered per account. All indications are that if your application is below these limits it’ll be free after the trial. The interesting part is yet unannounced payment structure for more resource-hungry applications. Until then it is impossible to do a business comparison between Amazon’s and Google’s offers — they are very different technically.
One of the biggest drawbacks of Amazon AWS is the uptime. Amazon promises 99% uptime, which is not enough. Just imagine that your application can be randomly unavailable 15 minutes a day or almost 2 hours a week potentially at traffic peaks, when you want to serve users the most. Would Google App Engine be more reliable? Only time will tell.