When thinking about applications in the cloud, it's best to think of new applications, applications oriented toward Web operations, and applications that do things in a way that's contrary to what you're accustomed to. In other words, think about using Google Bigtable.Google doesn't do things the way they've been done before, and that's a good thing. It's also a reason its offer to run your application under the Google App Engine merits a closer look. Chances are, you will want to create a new application to run under App Engine rather than move an existing one to it. If you want to run an existing application, it will have to be written in Python, or should I say, rewritten in Python, version 2.5.

Support for another language is coming soon -- this quarter, according to Jeff Scudder, Google manager of developer programs, speaking at the Cloud Connect conference at the Computer History Museum in Mountain View yesterday. "I can't tell you which one," he added. That's another feature of cloud computing; you will need to have a lot of faith in your supplier. One questioner asked how Google managed load-balancing queries across its massive amounts of data. "We don't really publish that. We just say, 'Let us take care of it,'" responded Scudder.

Indeed, in a quick conversation with Google's senior product manager Rajen Sheth at the same event, Sheth said Google's language support for App Engine is likely to expand to cover additional scripting languages, such as PHP or Perl, and to cover enterprise computing languages, such as Java, the C family, including C#, and maybe even legacy languages. That would make it conceivable one day to run legacy applications under Google App Engine, he agreed. But that's over the horizon; right now, there's only Python. So if you're willing to build a Python 2.5 application, it will be able to use a Google API that calls a Bigtable service. It's a data storage service, but instead of using commercial relational database, App Engine uses a Google-engineered database that stores your data in a single, large table.

Bigtable has some but not all relational characteristics. Relational systems draw from multiple tables; if your data goes into Bigtable, it will be accessed, updated, and treated as a single table, which it is. The table can be indexed in various ways, including as a column-oriented database, meaning similar information built into the same column will be retrieved with lightning speed.

Bigtable makes use of Google's Distributed Data Store across multiple machines. So retrievals will be done using Gql instead of SQL. Gql is a lot like SQL, but it doesn't allow joins, so a request to combine data from multiple tables will not be accepted. But then, all your data is in one Bigtable, right?

The simplicity of organization of Bigtable, its distributed operation, and its fine-grained indexing make it possible to conduct fast data searches and instant, big retrievals.

Modifying or retrieving data in a Bigtable can take place through a heavily parallelized process called MapReduce, which splits a task across many machines to be executed concurrently with a result returned to the master machine.

As evident in Google searches, Bigtable can quickly generate massive amounts of data for millions of users at a time.

Could you use such a service? Of course you could. As your new Web-based e-commerce picks up steam, you'll need Bigtable, Distributed Data Store, and MapReduce (again, that's a specialized Google programming function, not zooming in on a Google map location).

Computing in the cloud will make possible things that you didn't think you could do before, but learning the restrictions of the cloud will be your first task. Reaping its rewards, your second.