Skip to main content

Google App Engine & Java Hosting - Oh My!

Posted by wiverson on April 16, 2009 at 3:51 PM PDT

Over the last few years, I've been watching the various cloud computing initiatives with great interest - at the most basic level, I love the idea of being able to abstract the hardware purchase and spool up new virtual instances (or even just pay by the CPU cycle).

There are a number of interesting packages out there that offer cloud computing - for your reference, here are a couple I'm tracking:

http://aws.amazon.com/ec2/

http://www.mor.ph/

http://www.stax.net/

http://code.google.com/appengine/

http://mediatemple.net/

http://www.3tera.com/Get-A-Grid/

http://www.mosso.com/

Flipping through the documentation for these different sites, one thing that you'll notice is there are no consistent standards for what is and what is not allowed, how the apps should be packaged, etc. Some assume a complete virtual machine, with your own app server, others assume a WAR, others customize the deployment even more (perhaps with their own added descriptors). Most interestingly, all support different chunks and extensions of the JDK.

Even if you don't like picking and choosing interfaces, the simple fact is that there are no good standards for Java-based web application hosting. All of the specs for Java pretty much assume that you are running your own web server on your own private host - which means that everyone pursing Java in the cloud basically has to make it up as they go along. It's not meaningful or appropriate to require a hosting provider to provide support for every last bit of cruft in the JDK (e.g. CORBA), but there also is no good mechanism for sorting out how this works. It's also considered good practice to not allow web apps to do things like System.exit(). The examples go on and on - and this is part of the reason why it's hard to find inexpensive entry-level Java hosting (certainly as compared to ubiquitous cheap PHP hosting).

So, in no particular order, here are a two basic questions that should be informing the debate:

- How should a cloud service vendor indicate and choose what is supported by their platform?

- How should developers expect to package their Java application for the cloud?

A long time ago, the notion that you could reasonably expect to drop a WAR file into an app server and have it work was a pretty big deal. It was never perfect, but it did give you something to shoot for (and as a side note, that plus persistence via Hibernate always did work a lot better than EJB 1.x-2.x). That positive, simple vision is what drove Java.

I don't know precisely what combination of specifications, standards, and marketing is needed (Cloud Application Resource files, Java Cloud Edition, Certified Cloud Platforms... oh my!), but that's a more constructive conversation - and one more likely to produce results - than arguing over interpretations of specs never designed to support cloud computing.

I would certainly hate to have to point to any other competitive offerings as a possible source of the angst over interpretations of "pure" Java...

Related Topics >>

Comments

I think that the first thing we need is to agree on a common vocabulary for the new thing. "Cloud" still means too many different things. Just with the couple of comments above, plus mine, you find many different levels: + prime21 has a nice and simple application. It's the typical simple web+persistence stuff and I understand he's fine with GAE/J. GAE/J for him probably just means "free hosting that works and I don't have to manage the fucking server". The "cloud", intended as location trasparency, has no meaning for him, but the fact that it cuts down costs for Google and makes it possible for Google to offer a free service. + coding has similar needs that I have at the moment (probably mine are more complex, but fit in the same slot), as I find that virtual hosting (mine is PerformanceHosting.net) is the best solution for me. I need to run: a CMS (InfoGlue), Jira, Hudson + a couple of small applications and I need to manage subdomains *.tidalwave.it sharing the same CMS instance, so they must be co-located. Absolutely impossible to run them on GAE/J for many reasons. Again, this is traditional hosting, not really computational intensive and pay per cycle is not needed. PerformanceHosting is providing me with a JDK6, a Tomcat instance that they manage, and a web interface for administering MySQL data sources. I deploy applications in form of .wars through the simple Tomcat web admin and it works pretty damn'd good (and, hey, InfoGlue and Jira aren't "simple" applications). + I've another relatively small need, similar to the above in complexity, that needs image manipulation. Killed by the lack of some classes in the JRE. + And then there is the stuff that we used to call grid computing. I have an idea about a service for users that need heavy computation, can be relatively easily parallelized and the pay per cycle thing would be ok. EC2 is the slot that I need here. + The Sun Cloud offers virtualization of the o.s. too. This is a field where you can enjoy Hudson CI integrated with virtualized operating system for automated testing of projects in a different of deploying scenarios. Of course, I think there can be many more scenarios. What's happening is that cloud-like solution, that once were only related to grid-computing scenarios, thus in the upper part of the pyramid, are now getting easier to deploy and cheaper (even free), thus crossing the traditional hosting. This is very good, of course, but is getting thing more complex since more people and more scenarios are thrown in the arena. I mean, the noise now is not made only by corporate marketing guys, but by end users too. "Cloud" can't be used without ambiguity in all this mess and this is why I'm advocating for a better vocabulary. For what concerns the compatibility stuff, well, first and foremost people shouldn't call Java what it's only a subset of Java. Second, once you have clarified the most typical scenarios, people could define a set of "profiles" identifying the proper Java subset they need. I've read that Sun, IBM and others have started to talk about compatibility profiles, but I fear that it will take a lot of time for getting something useful (if it ever comes). Just see at how long it took for doing a similar thing in the Web Service field.

I stay away from pay per cycle and cloud stuff. My projects tend to be much smaller, but I use hosting companies that just give you a Linux like VPSLink, Linode or Slicehost. Those three tend to have the best prices for that, plus there's no features that lock you in.