Facebook Twitter Gplus
Home Technology Google App Engine Google App Engine – Proof of Concept
formats

Google App Engine – Proof of Concept

PartneredWeb today announced the completion of its proof-of-concept web application based on Google’s App Engine (GAE) cloud platform.

The site serves as a US corporate directory providing information, reviews and social commentary. Here are a few links:

Amazon Corporate Office
Geico Corporate Office
Search Page

Add review for a company you like and let us know what you think.

Application Platform Requirements

Our envisioned application suite will focus on the social space, and so we needed something that would scale up dynamically both in terms of data storage as well as requests per second.  We made a strategic decision to choose a cloud-based solution but also to select something that would enable us to not only avoid hardware purchases, maintenance, obsolescence, etc.

More importantly, we needed a solid set of operational technologies to base our work on.  As a small team, we had an imperative to avoid the need to support operations ourselves.  The goal was to free ourselves from having to constantly deal with server configuration, upgrade, compatiblity, etc., types of issues.  It was felt this choice would pay us back many times over.

For language choice, we considered the very popular / tried and true (PHP, MySQL), the new and cool (Ruby on Rails, Play Framework, Grails, etc), and our old favorite Java.  Our team is highly experienced in enterprise level Java applications.  Because of that we have a strong bias toward that language and technology stack.  The others offer some attractive options, but we thought it best to avoid adding another learning curve to the mix, at least in the beginning.

Platforms We Considered

Amazon Cloud, Google Cloud and Heroku.

Amazon is intriguing no doubt.   It supports a high degree of flexibility and can host virtually anything you care to deploy.  The big drawback for us was the need to configure the virtual instances, build or select images, pick and configure your storage requirements, spin them up and down, back them up, define your redundancy parameters, etc.  This is clearly a great option for teams that want or need complete control, but for us this is just overkill.

Heroku for Java looks to fit the bill nicely.  This is a great competitor to GAE and something that we plan to try out very soon.  It is a polyglot platform where language choice is really a matter of syntax and library support.  They have (like most) turned their backs on JEE in favor of the containerless elastic application platforms (EAP).  The platform is a bit younger than GAE and, well, Google just seemed like a better bet than Salesforce.  There have been reports of Heroku instability, so we committed to trying GAE cloud solution first.

We Chose to Use Google App Engine

GAE is a cloud-based infrastructure that gets you from soup to nuts with absolutely no concern for the environment required to scale.  It leverages Google’s Big Table columnar data model that many (most) of Google’s applications including search are written on. Assuming your application fits within the confines of No-SQL limitations, you can enjoy virtually unlimited scale characteristics offered by the platform.

GAE supports three language bindings, Python, Java and Go.  Forgetting the last, Python is definitely the lead dog in terms of when new features are rolled out on GAE.  However,  the Java bindings don’t lag too far behind.  Another factor to consider is stability in production.  Our research pointed out that Java tends to be much easier to manage in production due to its superior error handling and reporting techniques.

There are a host of services that GAE supports.  However, you have to be certain that the tools you need will run in this environment.  For example, lots of people love to use Spring IoC.  The problem in GAE is that the system spins JVMs up and down all the time. Any given user (and perhaps many of them) will experience the full startup overhead of your service stack.  Because of that, and knowing how much overhead Spring brings with it, we chose to go lite– no IoC for this round.  The app as a result will load from dead stop (or freshly upgraded) on about 5 to 8 seconds.  This has been acceptable compared to a reported 30 to 45 seconds for those burdened by a Spring container.  (If someone wants to refute that, cool.  We have not used Spring with GAE so this is conjecture).

You must rethink how you model data in this environment.  We are using the Objectify persistence library instead of dealing with the datastore’s low level APIs.  There is a DAO and JPA binding for the datastore, but they are not well regarded mainly because the datastore is very different from your usual SQL-based RDBMS.  I recommend viewing this Google I/O video to get a feel for what the datastore is like to use.

Other Technologes 

The front-end leverages JQuery and Twitter Bootstrap.  I highly recommend both.  We use a combination of JAX-RS based services.  We use the JBoss RESTEasy library which has been nothing short of flawless.  Also, for server-side rendering, Freemarker template engine does a fine job.

 Conclusion

Our GAE proof of concept has been a success.  The datastore takes some getting used to, but if your problem domain can fit within its considerable raft of limitations, you’ll be pleased by the effortless operations you will enjoy once your app is deployed and in the wild.

 

 

 

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments