Up until recently I hadn’t payed much attention to Google Apps Engine.  Last month I attended the Google Atmosphere event in London and got a quick run down on Apps Engine from one of the Google Engineers at one of the stalls, I have to say I was very impressed with what I saw.

Google Apps Engine is one of the Cloud Computing offerings in the rapidly emerging segment of PaaS (Platform as a Service). Other significant competitors in this arena are Salesforce.com with their Force.com platform, Amazon.com with their AWS (Amazon Web Service) offerings and Microsoft’s Azure.  Interestingly, Google had invited both Amazon and Salesforce to present at the Google Atmosphere event while Microsoft were at their own event launching Windows 7.

Traditionally when you wanted to build and deploy Web Applications / Sites you had to arrange hosting, or worse deploy servers.  This typically had to be in place before you touched a line of code and often times ended up being a messy, time consuming and expensive affair. Now with Google Apps Engine all you need is a Google account and the ability to use Python or Java.  The best part is that its free for modest sized apps/sites (up to about 5 million page views per month) and has reasonable usage charges beyond that.

You do have to give consideration to what you are signing up for before you get started. Unlike developing your solution on a LAMP stack, your Google Apps Engine project isn’t going to be easily portable, you do retain ownership of all your data and can export this at any time to migrate it elsewhere, but bear in mind that the data is stored in what Google call “BigTable” database and is accessed via GQL (Google Query Language). GQL has a similar syntax to SQL but the underlying data is stored very differently.

Force.com, Amazon S3/SimpleDB or Microsoft Azure all present similar issues but you have to balance these concerns with the benefits of the platforms.

This is not a statistical fact but I suspect that the majority of web applications that are written are in the “throw away” category, that is that they are either never brought to completion, are not implemented if they are completed, are built as a pilot or are built for a finite short term purpose. Only a small percentage of applications that are launched ever run into the happy problem of scaling but if your application does fall into this category you don’t need to worry if its built on Google platform, you seamlessly get access to the vast resources Google runs its own business on.  If on the other hand your application fell into the “throw-away” category you will have benefited because you didn’t wast time, resource or money worrying about the stack.

Some of the really nice benefits of the Google Apps Engine are the ability to seamlessly use most of the other Google service offerings via simple API calls, indexing, mail, docs, image manipulation, Google Talk and Google Maps to name a few.

Additionally I have seen a good deal of discussion on, what I consider to be a plausible argument that Google will be on the market to buy successful and innovative applications / companies that use the Google Apps Engine.  Google is renowned for its preference to buy early stage start-ups and after all if they buy a company that has deployed a successful app on its own engine, they will have little integration work to complete besides changing the name and the logo.

As always your thought and comments are appreciated.

Tweet This Post  Digg This Post  Reddit This Post  Stumble This Post 

Tags: Amazon, AWS, Azure, Cloud Computing, EC2, Google, Google Apps, Google Apps Engine, PaaS