With Google's App Engine, you write a bit of code in Python, customise some HTML, and bingo, you've got your database-backed dynamic website up and running in a few short minutes. When the world starts flocking to your web application Google's cloud of computers adapts to the load, handling everything the public demands.

One of the joys of being a web programmer is heading to a dinner party, a haircut, or a reunion and fielding the pitches for everyone's dream for a brilliant web application. Everyone is always happy to cut you in for 5, 10, maybe even 15 percent of the equity if you just build out the website that's sort of like a combination of Twitter, AltaVista, Eliza, TurboTax, and the corner chemist, but cooler.

Google App Engine is meant for dreams such as these. You write a bit of code in Python, customise some HTML, and bingo, you've got your database-backed dynamic website up and running in a few short minutes. The magic comes when the world starts flocking to your web application, and Google's cloud of computers quickly adapts to the load, handling everything the public demands. There's no need for you to buy servers, load balancers, or special DNS tables. Google's application cloud handles all of the grungy deployment headaches.

We played around with the App Engine SDK and, sure enough, developed and deployed applications on the desktop with just a few minutes of work. We didn't upload them to the cloud because we didn't make it into the beta program, but we were able to simulate the experience on our office server. The billions of hits haven't shown up yet, but it has only been a few hours now. It works and it is quite simple.

Google me this

A trickier question is deciding whether this is really what a future web application really needs. There is little doubt that App Engine makes it simple to get incoming data, make some decisions, store it in a database, and then move on. The more complicated questions are often political, technical, and almost aesthetic. There will be a number of programmers who look at App Engine and melt with excitement, and there will be many who tilt their head like a dog that can't understand his master.

Being a Google Python lover certainly helps, but it isn't necessary because the language isn't that much different from the other scripting languages. A good programmer should be able to shift gears quickly and easily. There are rumours that Google has a number of other languages waiting around the corner, but there are equally good arguments that this may not be happening as soon as some devotees would like.

Java programmers, in particular, are used to being known as providing the most scalable and flexible applications because the language and the API are some of the most sophisticated ensembles around. The J2EE standard nurtured tools that simplified some of these problems, even though it never really turned out to be as simple as the sales literature promised.

Today, Java's sophistication is probably hurting the language as much as helping it. A quick survey of web-hosting services shows that shared hosting for JSP applications begins around a tenner a month, while Python shared services can cost as little as £1 a month. The JVM may speed things up and provide better service, but it comes with a hefty memory footprint. If the brutally competitive web-hosting business can support five Python sites for every Java site, then perhaps Google is more interested in the long tail, the niche websites, than the big iron.

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.

NEXT PAGE: smells like SQL > >