Google App Engine and the end of Java hosting?

Last week Google announced Java support for Google App Engine. It came as a surprise because for a long time everything suggested Google would choose a different language given the well-known difficulties of hosting Java. Those were the hints, or at least the Java community’s reading of them, and Google never commented. Perhaps that worked out for the best. It avoided the pressure of announcing support before it was ready. Behind the scenes, work continued on a way to run Java web applications.

It’s worth asking why Java was ultimately chosen. It was probably pragmatic. Java support means a working Java Virtual Machine (JVM), which can host other languages such as Ruby and Groovy alongside Java. That must have counted in its favor.

Technically, it’s worth looking at how Google addressed the difficulties of hosting Java. Creating new threads or shutting down the JVM are relatively easy to police. More interesting is the 30-second limit for responding to a request. If the application doesn’t respond in time, the user is out of luck. For scalability, Google App Engine encourages applications to keep as little state as possible in HTTP sessions. Forget sticky sessions. Every request could go to a different server.

Within hours of the announcement, people were speculating about whether this would spell the end of competing hosts. I don’t think so, for purely technical reasons. An App Engine application can scale almost without limit, but the compromises in implementation come at a steep price. Try moving a conventional Java web application and you’ll probably regret it. Besides its heavy use of sessions to maintain conversation state, the biggest problem will be the relational database.

We’ve spent twenty years building applications on relational databases, and Google App Engine doesn’t offer one. It uses BigTable for storage. With the Map/Reduce framework, BigTable offers remarkable scalability for data processing, but there’s a catch. App Engine offers a higher-level abstraction over BigTable in the form of a pared-down JPA or JDO implementation, yet it’s a fundamental shift in how you think about storing and working with data. There are practical consequences, too, for the tools and methods people have relied on for a long time.

Google App Engine plainly won’t suit every kind of web application. When scalability isn’t the main criterion, the interesting possibilities come with major compromises in design and implementation, most importantly in storage and data access. That’s the main reason I don’t expect applications to move to App Engine en masse. Rapid growth in virtualization has also brought some interesting little clouds, such as Stax, that offer Java as a service. With that approach you get Tomcat and MySQL and pay for data transfer and processor time. You avoid making big compromises in areas where your application probably doesn’t need them.

Sources

• InfoQ Google Brings App Engine’s Pros and Cons to Java
• JavaLobby Java on Google App Engine — Time To Play In The Cloud
• JavaLobby Java on Google App Engine