Last week Google announced AppEngine: a service that provides the option to deploy custom applications on the legendary Google infrastructure.

Nowadays there are tons of hosting solutions available offering a huge variety of features; nevertheless, Google’s new service has some unique functionalities not available elsewhere. To me, the most interesting is BigTable; the persistent engine used by Google itself to implement its own services.

BigTable architecture is quite odd, if compared with common DBMS accessed using SQL. And the different architecture requires a different mindset in order to use it efficiently. Brett Morgan wrote an effective description of the very different perspective that BigTable requires:

Remember what GFS and BigTable were originally designed for. Each BigTable entry contained a whole web page, and all the data relating to that web page as the various stages of the google processing pipeline are applied to the page. So storing two numbers in a BigTable entry is like putting a person in a 747, then complaining how long it takes to get the person 50 feet along the ground in said 747 - it would be quicker to get the person to walk.

The power of BigTable comes to the fore when you fill the 747 with people, fire up the engines, and then get the aircraft to cruising altitude. That’s when you are using the tool properly.

Clipperz online password manager does not really require all that power since its zero-knowledge web architecture moves almost all of the computation to the clients, leaving to the server only some trivial tasks that can be executed with very little resources.

However, since I had recently ported the Clipperz backend to PHP, I though it would be nice to port Clipperz to Python too, with the extra bonus of testing BigTable on a real, even if quite simple, problem.

In a matter of a few days (mostly due to my complete lack of experience with Python) I have been able to run Clipperz on the AppEngine SDK. It works fine, but I don’t have an account on the real thing yet, so I cannot say much about how the aforementioned constraints affect the behavior of the application.

The most difficult part was to avoid Google’s authentication service and implement a custom solution to manage sessions (still very rough) in order to allow users to perform a more secure SRP authentication.

Experiment outcome:

• BigTable is quite impressive; simple yet very flexible, with the intriguing promise of unlimited scalability.

• Clipperz’s server side code base is not very suitable for a massive application of the map/reduce pattern, but it is very easy to port to different platforms

At the moment we have no plans to officially release the AppEngine version of Clipperz, but if you are interested in playing with the code, get in touch with us.

So, what’s the next experiment? A different client for a very popular platform to prove how flexible is the Clipperz’s architecture. Stay tuned!