[Tech] Google AppEngine (and Java)

AppEngine is a rather recent new service from Google. It is probably Google's answer to Amazon's cloud-computing platform, yet targets a very different market. Where Amazon offers a a broad range of services and high flexibility (with the disadvantage of higher administration effort) Google targets web-developers that want to publish web-applications. AppEngine started with a Python environment, now since some days the long anticipated Java-version (Java 5 and 6) is online. Now what are the benefits of using AppEngine?

Java

First of all, it is possible to deploy applications without having to install, administrate and maintain an own server (instance). Google provides a runtime environment (sandbox) into which Python or Java applications can be deployed. Access to these applications is (for clients) only possible via http(s). So this is a feasible approach for web-applications or RESTful services.

An additional advantage is, that Google deals with scaling issues, i.e. it scales the applications dynamically to the demand. This is a significant advantage for startups, that have no clear idea about the number of customers they are going to have or how fast this number is growing. For the scaling to work, though, some restrictions have to be considered. Most notably this concerns the persistence strategy. E.g. applications (and libraries!) are allowed to read files from the filesystem, but are not allowed to write. For all persistence issues, the Google datastore has to be used. However, what is nice with the new Java-sandbox is the fact, that Google apparently tries to follow established standards. For persistence Java developers can use JDO or JPA or a low-level interface for the distributed datastore.

I wonder, however, how logging can be handled in that environment. Logging is usually done to a file or to a JDBC datasource. A JDO logging target I have not seen before; ideas anyone?

Generally spoken, arbitrary Java libraries can be deployed and used in the AppEngine as long as they do not violate the AppEngine sandbox. Also due to the scaling-approach not all libs/frameworks will run unchanged. As yet, it seems not quite clear for example, which Java Web-Frameworks will run seamlessly in the App-Engine. Googles webtoolkit (GWT) should work, other framework communities are currently testing their frameworks for compatibility, e.g. in the Apache Tapestry and the JSF framework Apache myFaces discussions are running on the mailinglists.

Build Automation and Development Process

The development process is, in my point of view, as also with other Google environments like GWT a mixed blessing. Everything is Eclipse centered, which is not really a good thing: Google provides an Eclipse plugin for the AppEngine including a runtime environment for testing applications offline. This is great for daily development activity, but not for a stable build- and testing environment. Unfortunately Maven support (like archetypes) are completly missing at the moment. Google is apparently pretty hostile towards Maven and focuses mostly on IDE integration, which is definitly not a sound way for a modern build automation. IDE "wizard-based" SE approaches usually turn out to be unstable and problematic, particularly in team-projects. This might be nice for a fast hack, but is no basis for a larger project. It seems, that some support is given for Apache Ant though.

Hopefully other developers will provide a Maven integration for the Java AppEngine. With the current approach not even an IDE-less deployment is possible.

Conclusion

So, despite of the build-issues, I believe that the AppEngine is a great option to deploy web-applications in Java or Python. For small applications (small in the sense of "low web-traffic"), the AppEngine is free, after exceeding certain thresholds (CPU, storage, bandwith...) one pays according to the resources needed. Google provides a web-interface to set daily financial limits for individual resources. E.g. one wants to spend a maximum of 5 $ a day for CPU time and so on.

Looking forward to the first experience reports, particularly with web-frameworks like Wicket, Tapestry or Cocoon.