Java in the cloud: Google, Aptana, and Stax

Google App Engine, Aptana Cloud, and Stax for EC2 make it easy to spin up and scale a simple Java Servlet Container, but are still a far cry from the full Java EE

Page 3 of 8

There are also a number of restrictions on the classes you can use. Google's version of the JVM isn't fully stocked. You won't be able to spin off a thread to handle processing and you can't write to the disk -- ever. You have to use Google's data store if you want to save the data.

All of these changes have some advantages. Google's data store is stripped down and optimized for working with many machines at once. The Memcache service saves calls to the data store -- something to be wary about because the meter is clicking whenever your servlet is churning. The image processing tool handles some of the work with native code, another advantage.

For all of these reasons, I think App Engine will be most attractive to projects that need to give people shared access to several big tables filled with data. It's not really for all Java programmers, but for people who are familiar with Java and like to use it to write some glue code to wrap around a big table. You can't do too much to the data on the way in or the way out because there are limits on the amount of time that each request can spin the meter.

google_sm.gif

I think these restrictions will mean that there will be relatively few applications that just pick up and migrate to the App Engine. All of the data access will need to be rewritten and some of the common tricks that use flat files will need to be re-engineered. Moving your application out of the App Engine will probably be a bit easier, but it will require changing your mindset because the App Engine used to handle some of the scaling and synchronization issues for you. It may be technically possible to run the App Engine debugging environment on your own server, but the Terms of Service say Google is giving you a license for the "sole purpose of enabling you to use and enjoy the benefit of the Service as provided by Google, in the manner permitted by the Terms."

Google is well aware of this issue and is trying to address it as it encourages people to use the system. IBM is even offering tips on how to migrate App Engine code to its platform. It's just a matter of getting the JDO (Java Data Objects) calls to talk with IBM's DB2 instead of Google's back end. I'm guessing that IBM hopes to grab customers who build the first rev in App Engine and then decide that some threading or slow cron jobs are absolutely necessary.

I built several JSPs that deliberately sucked down a large amount of computation time, and it was pretty easy to push them hard enough to reach the limit. I don't think most Web 2.0 applications will run up against Google's CPU and memory limits, which are liberal from the standpoint of the typical Web application, but they could be a problem for anyone that wants to do much heavy processing. The image toolkit, for instance, will only work with images smaller than 1MB -- something that's a bit tight for serious photographers. My pocket camera, for instance, can turn out images that take up 4MB.

These limits might squeeze an application in unexpected ways. cron jobs are just URLs that are called at set times. That's a nice abstraction but it's definitely a bad fit for some of the massive reports that corporations generate every evening. It's more for housekeeping than any kind of asynchronous heavy lifting.

Related:
| 1 2 3 4 5 6 7 8 Page 3
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.