Cloud Computing Series: Exploring the Google App Engine Java Runtime Environment

• • Reply

  11 years ago

  by dhirajch

  dhiraj kumar

  Delhi, India

  Joined 11 years ago

  Google recently released a Java runtime environment for their App Engine platform. As a software development organization, this offering is of special interest to Nagarro, as it offers several advantages over competing cloud hosting environments. Hosting a Java application on Google’s infrastructure provides automatic scaling and load balancing, a feature that is of interest to a number of our software product development ISV customers. To better understand the issues and risks, we conducted an internal exercise to assess the technical effort required to port an existing application to the Google App Engine for Java (GAE-J).

  A Bit of Background

  GAE-J is a complete development stack that uses familiar Java technologies like JSPs, servlets and JavaScript to build and host web applications. With GAE-J we would write the application code, test it on the local machine and upload it to Google with a simple click of a button or a command line script. Once the application is uploaded to the Google infrastructure, it would host and scale the application for us. We would then, no longer need to worry about system administration, bringing up new instances of the application, clustering the database or buying new machines.

  GAE-J provides access to many popular services from the enterprise applications world, including a scheduler, logging that can be reported from the Google Application console, mail, caching and URL fetch. It also provides elegant integration with technologies like Spring, Sitemesh, Struts etc.

  GAE-J also makes it easy to serve static files like Images, CSS style sheets, JavaScript code, movies and Flash animations can served directly to the browser from separate servers that those that invoke servlets.

  As you would expect from initiatives by Google, GAE-J comes with extensive online documentation - including quick start guides which I found invaluable. Also, Google provides many tools that make coding and developer testing simple and quick. GAE-J provides a local sandbox (based on Jetty) that should be used for testing before deploying into the cloud. The development web server simulates the App Engine Java runtime environment and all of its services, including the datastore. The Google Plugin for Eclipse can run the server in the Eclipse debugger. You can also run the development server from the command line.

  Our Experience

  We found that using Google App Engine has great advantages, but it also has serious limitations. Google has implemented a tight security model on GAE-J, and you can’t write to the file system, it is read-only. You can only store data using the Google Datastore API. On first look, this seemed like a big restriction, but given the fact that the servers are clustered, it made sense in the long run.

  In the GAE-J sandbox, the application code only runs in response to a web request or a cron job, and must return response data within 30 seconds in any case. A request handler cannot spawn a sub-process or execute code after the response has been sent.

  Uploading the initial data is another challenge; however, that may be solved by providing the capability to upload data into the data store of the application itself.

  It is also evident that GAE-J is still in its infancy and has glaring restrictions (for example: GAE-J sets a hard limit to the number of application and static files in the application; refer to http://code.google.com/appengine/docs/java/runtime.html#QuotasandLimits.) IMO that needs to be addressed ASAP; to continue its evolution into a serious contender in the Cloud Services industry.

  In conclusion, we found that moving an existing project to GAE-J’s infrastructure is not a trivial job, but it can be done. There are a big number of areas that differ between traditional web applications and Google’s app engine. I agree with Abhijat’s post on Cloud Computing Demystified: Part-I# the real cost of using these services that identifying and reconciling all these differences would require significant work; esp. in view of the fact that in many cases it may be imperative that the changes (refactoring / re-organizations) made MUST work nicely with the traditional deployment as well. Specifically, certain areas such as the constraints from traditional relational database methodology, restrictions on the number of URLMap entries etc. may induce a re-design of the application and add to the challenges of migrating to the GAE-J cloud.

  It would be much easier to develop a new project on GAE-J where innovative architectures for an application could computing be explored, rather than trying to port an existing application.

  Report abuse