Cruising on the Google App Engine

Google country is an awesome country to visit. To cruise around this country, exploit its power and harness all its energy, you had to be a Google engineer. Well, not any more. Few Googlers have broke the barrier to Google's rich infrastructure in an interesting way and have give outsiders access to some of this infrastructure in a fashion, that keeps Google running as it always has, but at the same time support web applications made by bubbling artists like myself. However limiting the access is, the idea itself is phenomenal and to a web developer like myself breath taking.

Let's try to break down, what I as a bubbling web developer gets out of this genius product that some Googler probably thought of, while taking a shower.

Infrastructure
Google is built upon a solid infrastructure, which is one of its biggest strengths. It is massively scalable. It has been worked upon by some pretty smart brains and the best of all, it was built in iterations as Google's need and reach grew.

Abstraction
Imagine harnessing this infrastructure behind a simple query and API layer. You get the best of both worlds with such an approach. Access to a powerful infrastructure, yet safety and convenience features to keep your application from stalling other applications running on the platform. Additionally, Google engineers made sure, access was given to only those parts of the infrastructure that made sense, isolating the rest.

User support
Every application, well most, have users. Every application I have written or worked on modeled these as objects, added features so that rest of the application can interact with them. It was a tough job, because things constantly changed in the user area. Users came and went. Additional meta attributes was a constant stream and sometimes they had other accounts to fetch feeds from. Now consider this. Every Google App Engine application has access to Google users - users with Google accounts. And that is just the beginning.

Using Google Data API's you can access the user's contacts (with user's consent and thanks to Gmail) among other things. Even his/her bookmarks, calendar entries and other data services. It is true, that you are tying yourself to Google here as well (aka lock-in). But consider this, this is not needed. You can model your own user objects at will. Also since Google has such a large user base, it can even be a boon for smaller applications. And that is what the Google App Engine is focused on at this point. Not smaller in terms of scale, but smaller in terms of the number of users. When the app engine platform matures, it will be able to support applications on a much larger scale, and that will be sooner than you think. It is more about logistics, legal terms, service contracts, rates and those boring things. This technical marvel is here to stay.

Development console, analytics, GData API's galore, OpenSocial, oh my..
There are some wicked cool tools one can take advantage of Google's bucket. The app engine for example comes with a sleek administrative console to manage the web apps. Trust me, this is extremely crucial and one of the favorite features of Django a popular python web framework, which can also be used with the app engine. In fact, the app engine borrows some cues from this popular framework.

Also if you can commit on using Google accounts, you can take advantage of many Google data api's such as contacts, calendar, youtube ... which are available for many Google services and the offerings just keep on getting bigger, thanks to the developer excitement around this area.

Another Google tool that can be combined is Google Analytics, a fantastic tool to monitor and analyze the web app's uses, references, ads and so on.

OpenSocial also becomes a very viable option if Google user accounts are used by your web app.

Last but not the least, one is not restricted to any of this. It just is a whole lot easier to add these Google services to the bucket, but one can easily build upon say the Facebook API.

An awesome query language
Building on the datastore is not easy especially if you are used to relational databases, esp the query and reporting part. But no worries, the app engine data store comes with an awesome query language (aka GQL) which is SQL-like but workes on Google's distributed file system (GFS). It is quite powerful yet easy to use and supprots indexes, transactions on entities, entity groups and models.

A rare treat
Upto this point writing an application using MapReduce, BigTable and GFS was only available to Google engineers. Since I did not wanted to work for Google, my personal, pet and other collaborative projects had a bare-bones start, often dying in a very early phase. It's amazing what a reliable and powerful, yet forgiving infrastructure gives. And it is equally amazing to think of ideas for this beast within.

Lock-in's
With those advantages, note these areas of potential "lock-ins" which might not be a huge problem for many many web applications to come.

• Infrastructure lock-in
• User lock-in
• Support lock-in
• API lock-in
  

These lock-ins might not be serious to many entrepreneurs and web enthusiasts for the benefits they get in return out of the Google infrastructure and support. Basically, most teams can eliminate half a dozen human resources in a < 20 people startup.

Other Limitations
Google App Engine is primarily a python programming environment. That might not be suited to few development shops or developers with other favorites. There is also a quota system, where the initial set of resources are free, but recurring costs are incurred when usage exceed these quotas - a perfectly reasonable limitation and a good one to keep the app engine going.

Have fun, Google App Engine is here to stay and this is just the beginning.