Four important things. Here's the fourth:
Google just released it in April to the public, and it is still classified as a 'beta release'
That's good news and bad news:
The good news is that it's free - totally free for now, and, according to public Google promises, always free to the small-volume user. They will, sooner or later, have a 'commercial' program, where high-volume users and users of special features will pay more. Google released a preliminary price sheet here.
The bad news is that it still has a few rough spots, limitations, and holes. Among the most notable are:
(a) The volume limits: only a few seconds per process, only so-many processes per day, only so-much disk space, etc. The real figures are here.
(b) The storage restriction: you can't write to a regular file, only to Google's "bigtable" storage mechanism, using their almost-SQL interface;
(d) No scheduled processes, e.g. daily 'batch jobs'; everything is triggered by a web request. There are some work-arounds to handle this - the most obvious is to set up a process on a machine of your own that sends a request to the Google App to "do its duty." And it seems pretty likely that the Google Apps developers will find a way to enhance Google App Engine to support this important requirement by itself.
Four important things. Here's the third:
3) It uses Google's custom-built data storage mechanism, called 'BigTable', instead of a conventional SQL-driven database.
Google has a detailed description here: http://labs.google.com/papers/bigtable.html
That's good news and bad news:
The bad news is that you have to re-write any existing applications that use SQL.
The good news is that the Google 'BigTable' is really easy to use, so it doesn't take long to write software to access your data ... assuming your data structures are fairly simple.
The bad news is that, if your data structures are complex, or if your current application depends on fancy features built into Oracle or SQL/Server such as stored procedures, JOINS, etc - you have a lot of re-writing to do.
2) It runs on the Google infrastructure: Google's hardware and system software.
The idea is that Google manages, for you, all of the operational adminstrivia, and they do it well: they have the resources to support multiple-redundancy, reliable backups, and scalability to any conceivable size ... unless your application is more complicated, or more popular, than the Google search engine itself, which just ain't gonna happen. Wouldn't it be nice not to worry about hardware failures, network failures, etc. Wouldn't it be nice not to need a DBA, a System Administrator, a Backup supervisor, a Disaster Recovery expert ...
And wouldn't it be nice to have predictable costs?
Of course, at the moment, the cost is very predictable: during the current 'beta' testing phase, it's free.
Four important things. Here's the first:
1) Currently, the only language supported is Python.
That's good news and bad news:
The bad news is, of course, that a lot fewer people can write Python programs, and there aren't many existing financial applications written in Python. There are, however, a lot of non-financial applications in Python, in sophisticated areas such as language processing, computer games, and even computer animation. "Every CG image we create has involved Python somewhere in the process," said Philip Peterson, Principal Engineer, Research & Development, Industrial Light & Magic. (as quoted on the Python website) The good news is that Python is a really nice language. Try it: you'll like it. The Google development team tried it, and they like it enough that they use it extensively in-house. They liked it enough that they hired the person who created Python, Guido Van Rossum. See his his personal web page, with a brief bio, on http://www.python.org/~guido/.
I wrote another blog article about Python here.
In essence, they are offering to be the 'operations department' for anyone's web-based application. They currently have a "beta" release, free, for developers to try out. So ... here I am, trying it out.
okay, that was pretty lame. I'll get around to writing a proper bio and put it up here someday soon.