Ben Cherian’s blog

In a earlier post, I explained my concerns about lock-in surrounding Google App Engine (GAE). I was told by the Google team responsible for GAE that many external developers have seen this issue and are developing products to solve the problem.

Today, I stumbled across two possible ways to port your GAE code without rewriting the entire app. The first of which is a proof-of-concept called AppDrop. AppDrop allows you to to move your app from GAE to Amazon’s EC2 without rewriting a single line of code. Of course, because the infrastructure model is significantly different, you won’t enjoy the unlimited scalability of GAE database, but it will allow you to do a temporary move while giving you time to figure out which database technology to move to.

The more exciting option is to use Massimo Di Pierro’s web2py framework. In version 1.30, Massimo added GAE support to the ORmapper in web2py. While full web2py functionality won’t be possible due to GAE’s restriction on writing to the filesystem, it still allows developers to move code between completely disparate environments and database technologies (mySQL, PostgreSQL, Oracle, SQLite3, and Google Query Language) with relative ease. All you have to do is add an import line to your python script! Check out this video for more info.

I’d like to see other python frameworks such as django, TurboGears, and Pylons make this functionality a part of their feature set. Since django and TurboGears have reasonably, deep Google connections, I would guess that there has been some internal discussion of this before.

These products only deal with the database layer and not every Google-specific call like mail or authenication. My hope is that there will be some traction on this front as well. In any case, it’s a great sign that many people are working to make code portability a reality for GAE apps…and that’s good for everybody.

Today was the last day for the Google I/O conference and I have seen some amazing products from the Google developer team. They have some very bright people working there. It must be a joy for them to know that their code has the ability to directly impact millions of people.

Checking out the latest advances in technology is like a vacation for me so this conference was a blast. The highlight of my vacation was learning more about the internal workings of Google App Engine. This technology has the potential of completing changing people’s expectations surrounding infrastructure. It’s allows a python programmer to instantly deploy a application without having to worry about infrastructure setup or whether the platform can scale. It has a logging api that publishes details to a straighforward management interface. On top of all that, it comes with authentication, mailing, image, and memcache API’s and a local development environment. In short, it’s a game changer!

While I love the concept and execution of App Engine, I am a bit worried about vendor lock-in. Let’s say you write a django app for App Engine that uses the GQL datastore, the mailing API’s and the authentication API’s, you won’t be able to pick up this app and drop it into a local environment or onto an Amazon’s EC2 instance. There will be many ”proprietary” API calls that need to be re-written to work in another environment. This means that there won’t be easy code portability out of App Engine. All your eggs will be stuck in a Google basket.

Today, Google had a fireside chat session with the App Engine team which allowed common folk to ask the team any questions about their product. I asked them whether or not they planned to release a GQL adapter for databases like mySQL or PostgreSQL which will allow GQL calls to stay the same across disparate environments. They responded that they aren’t building anything like that, but are enthused by reports that external developers are working on SimpleDB and CouchDB adapters. These databases are closer in philosophy to the GQL datastore than traditional relational databases like mySQL or PostgreSQL. The team also mentioned that they are interested in having standard API calls for all similar databases and that they would support such an initiative. Way to go Google! Hopefully, Google, Amazon and CouchDB will make this a reality. I’d like to see mySQL, PostgreSQL, Microsoft, and Oracle involved as well.

With GQL adapters in the works, I’m sure some enterprising developers will build App Engine connectors for the other proprietary API’s. Once this happens, lock-in is no longer a worry and all your eggs won’t be in the Google basket.