DZone recently caught up with Matthew McCullough, author of our 79th Refcard: Google App Engine for Java. Matthew is an Open Source Architect with the Denver, Colorado consulting firm Ambient Ideas, LLC which he co-founded in 1997. He’s spent the last 13 years passionately aiming for ever-greater efficiencies in software development, all while exploring how to share these practices with his clients and their team members. Matthew is a nationally touring speaker on all things open source and has provided long term mentoring and architecture services to over 40 companies ranging from startups to Fortune 500 firms. We spoke with him to learn more about Google App Engine for Java (GAE/J).
DZone: What Java frameworks are compatible with Google App Engine for Java (GAE/J)?
Matthew: There are five mentioned in the Refcard (Grails, Gaelyk, JRuby, Struts and Wicket) that have really become my preferred frameworks for the GAE/J platform, but many more are working towards fully supporting and conforming to its constraints. The interest in the Google App Engine platform is gaining incredible momentum for startups looking for proven scalability, and thus framework authors are taking notice.
DZone: What are some of the programming constraints of the GAE/J platform?
Matthew: The GAE/J platform has a well published whitelist of core JDK classes that are authorized for use. The classes that are disallowed are primarily ones that would impact the automatic scalability of GAE apps, such as java.lang.Thread, create a heavy dependence on the underlying operating system such as JNI, or require a file system such as java.io.FileWriter. That last banned class I mentioned exposes the fact that the GAE platform has no traditional file system and only allows for persistent storage in the Datastore, which is a set of highly scalable database-like tables.
DZone: How does GAE/J hosting work?
Matthew: Google gives developers a very generous free quota of apps, CPU, bandwidth and storage. This has really reinvigorated experimentation on the Java platform. There's literally no cost barrier to trying out an application idea with a few friends over a weekend and launching it at a dedicated domain name. Once you reach around 160,000 page views a day, you'll have the option to move up to a paid level of resources, in which you pay only for resources actually used -- not a fixed monthly price point like traditional hosting.
DZone: What is the GAE/J Simulator?
Matthew: Given the unique constraints of the GAE platform, Google smartly provided developers with a simulator web container. It provides nearly all the facilities of the production GAE platform privately, which can be used for rapid integration testing. All of the SDK-provided scripts and build tools seamlessly integrate with the simulator. Impressively, nearly every feature of GAE/J from Google Account authentication to the Datastore and even the Task Queue are implemented in the desktop simulator.
DZone: As my application needs to scale out, how does GAE/J facilitate this?
Matthew: For the price developers seemingly pay in conforming to the GAE platform constraints, the return on investment is paid in spades with scalability. As the load increases on your deployed application, Google adaptively uses a private back-channel network to distribute the application binaries to more nodes. Those nodes automatically and seamlessly start serving the growing load on your application. For data storage, Datastore has been proven to scale to incredible sizes by Google's own use of the technology in the Picasa, Google Search, Google Reader and Google Earth.
DZone: What type of constraints does GAE place around application scalability?
Matthew: Generally speaking, the sky's the limit in terms of scaling capabilities on the GAE platform. There is a usage ceiling for free accounts, and above those resource limits, the account holder has a dashboard to set thresholds for pay-per-use services that are billed to a credit card. The pricing is competitive with any other high-quality application hosting provider.
DZone: How does Bigtable technology differ from the traditional RDBMS approach?
Matthew: This is one of Google's greatest innovations, but also most noticeable deviations from the technology stack that many developers have become familiar with over the last few years. Datastore, which is a more developer-friendly form of the Bigtable technology, does away with traditional table-to-table relations. No RDBMS-like relational integrity enforcement exists at the data storage level. The data model is also typically more de-normalized than that of a traditional RDBMS application, with some data duplication actually being accepted as proper and sound design. The absence of join-style queries allows the data to effectively be sharded by the underlying Datastore, thereby bringing what is typically a human engineer scaling decision into the realm of automatic management by the GAE platform.
DZone: Are there any final words about the GAE platform you'd like to share with the readers of your Refcard?
Matthew: In closing, I'd like to encourage all Java developers to take a quick spin with GAE/J. The concepts embodied by this platform, created by the developers at Google -- some of the most respected scalability software engineers in the industry -- are spreading even outside the GAE platform. Developers who explore the App Engine platform now get a glimpse of the future of scalability techniques that will eventually become the baseline on the JVM platform.