Has Google App Engine Lost the Steam?

PaaS is creating quite a buzz in the Cloud Computing world. 2011 saw a plethora of new entrants and major enhancements to existing PaaS offerings. Heroku, Cloud Foundry, Engine Yard, Beanstalk, Windows Azure, Force.com, OpenShift and even lesser known stacks like dotCloud managed to be in the news and got their share of media attention. But one key contender has been missing in action but managed to be in the news albeit for wrong reasons. And, that is Google App Engine!

Don’t get me wrong. I love Google App Engine and spent significant amount of time learning the stack. I also recommended it to a few startups to host their social web applications. I had high hopes of it when it was first announced in 2008. At one point, GAE was the only PaaS to support both Python and Java. But in the last couple of years it lost the steam. Initially Startups loved GAE and so did the developers. It was primarily because of the free thresholds and the investments made in the form of SDKs and plug-ins. The other reason could also be because of lack of choice. Python and Java developers never went to Windows Azure which was the only alternative to GAE at that point. Slowly Heroku became at alternative for Python developers and started to grow at the cost of App Engine. But during the early days, Google missed the great opportunity to on-board massive number of applications onto the platform and also the opportunity of engaging with the critically important community of developers. So, what went wrong with Google App Engine?

Heavy Refactoring: The primary concern with GAE is the amount of change that needs to be done to port an application. And once deployed on GAE, it has to consume the proprietary APIs that make it extremely hard for the application to get out of the platform. Even standard Java web apps need to go through a lot of refactoring to run on GAE. Google’s ‘Touch Me Not’ policy with the underlying Java and Python classes worked against its adoption. While Heroku kept adding features and provided better control, GAE went on to constrain the developers through its proprietary APIs.

Pace of Innovation: Microsoft, which is known for long release cycles managed to update the Azure SDK multiple times and improved the management portal frequently. GAE remained in perennial beta following the Google tradition. It remained in Preview mode for almost three years! This did not give the confidence to developers to move production applications. While Google did move fast on the features in the last one year and introduced some of the most wanted capabilities like Backends, Pull Queues, Cloud SQL and Blobstore API, it took a long time to respond to the customer needs. These features were essential for certain workloads to move to the Cloud.

Perception of GAE being a Glorified Web Host: For a long time, GAE only supported stateless web applications. Technically, this restricted the scenarios only to consumer web applications that didn’t have complex business logic. For example, Windows Azure has Web Roles to run web applications and Worker Roles to run long running processes and complex business rules. Same is the case with Heroku which let’s the application run across the Web Dyno and Worker Dyno to split the functionality. Lack of support for such partitioning of an application for a long time (till the introduction of Backends in 1.5.0 released in May 2011) made it difficult for migrating line of business applications. Though it was possible to emulate the Worker process through a combination of Task Queues and Scheduler, it created a perception that GAE was only a glorified web hosting environment.

Data Access Strategy: For a long time, Google App Engine stuck with Big Table as the primary data store. Amazon kept improvising the database offerings by adding capabilities to SimpleDB and also launching RDS that provided traditional database as a service. Lack of a proper transactional data store on GAE became a huge limitation. Any serious application needs a combination of relational and NoSQL database to scale on the Cloud. GAE’s Datastore did not offer the capabilities that were required by data intensive applications. Even services like BlobStore and Cloud SQL came in much later.

Product Positioning: GAE had a great opportunity to lure the startups by becoming an affordable platform. It could have very well been a preferred platform for deploying consumer web applications. But Google’s positioning has been confusing right from the beginning. Typical low end web applications that were ideal candidates for App Engine have gone to Heroku while high-end workloads kept moving to Amazon EC2. Amazon’s announcement of Micro Instances and Free Tier hurt GAE further. Even today, it is very hard to visualize where GAE fits in the overall PaaS Landscape. Is that meant to run low-end web apps? With some of recent additions to the stack, is Google eyeing for line of business applications? The positioning is still unclear!

Pricing: While no one likes a free service turn into a paid service, Google had to make money from GAE. But the developers felt that the pricing structure of Google App Engine was unreasonable. There was a hue and cry from the community when the new pricing structure was announced. Many customers realized that they would be charged 3x-5x of their current bill. This did not go well with the community. I know at least three startups that moved away from GAE to Amazon EC2 and some even preferred a classic web hoster to GAE.

There are some more factors that I noticed with GAE.

• When compared to the attention Android gets, there is always a discomfort among the GAE developer community that the App Engine is a second-class citizen for Google.
• At Google I/O in 2010, VMware and Google announced a partnership to bring Spring to GAE. I expected that VMware would leverage GAE for their PaaS strategy. But VMware went ahead and acquired RabbitMQ, WaveMaker and Cloud Foundry as a part of Spring Source. That was a clear indication that VMware was moving towards it’s own PaaS. While Cloud Foundry emerged as a true Open PaaS, GAE hasn’t progressed much.
• Another blow to Google came when Patrick Chanezon, the rock star evangelist of GAE left them to join VMware. Patrick now heads the Developer Relations at VMware and is busy evangelizing Open PaaS to the developers. This underscores my belief that Cloud Foundry will be a dominant PaaS player in the days to come!

- Janakiram MSV, Chief Editor, CloudStory.in