Java in the cloud: hardware-free miracle drug?

But still, the idea of being able to just dump a JAR or WAR file onto the cloud and letting it do the rest of the work is hugely appealing. If Google got one thing right with App Engine, it's the ability to drop Python code onto the server and be up and running. And while you can support pretty much any language in a VM - Perl, PHP, .NET and so on - direct deployment to infinite scale is the promised land.

Cloudy or just hazy?

There are not many well-rounded cloud configuration tools available. This fact is just a function of the nascent stage of the market: the cloud is nowhere near as packaged as you see with something like Linux, where distros like Red Hat and Ubuntu offer ways to manage and update the packages.

In order to actually use EC2 we can grab some pre-built AMIs, or build our own. You can do so via the command-line, or install Elastic Fox, a Firefox extension for interacting with Amazon EC2. Amazon has a decent collection of AMIs for you to download here.

Now we have AMI. Let's fire it up. Again, we can use ElasticFox, but for example purposes, we'll SSH in and use Amazon's command-line tool to start our AMI instance and our Tomcat server.

Dave-ElReg:~] dave% ec2-run-instances ami-Tomcat -k gsg-mykeypair

There you go. Our AMI is live. Simple as that.

Now we're ready to deploy our Java code out to EC2. Odds are most developers use some kind of build tool. Let's assume we're using Maven for our builds: we can then grab a copy of Cloud Tools and use the Maven plugin to deploy to EC2.

Excellent. Now our application is compiled and running and we can access it via the URL that Amazon provides when you sign up for EC2.

Done and done. Let's say you want to delete an AMI. It's easy. Maybe too easy.

[Dave-ElReg:~] dave% ec2-delete-bundle -b <your-s3-bucket> -p image -a <aws-access-key-id> -s <aws-secret-access-key> 
Deleting AMI bundle parts from https://s3.amazonaws.com/<your-s3-bucket>...
Deleted image.part.00.
Deleted image.part.01.
Deleted image.part.02.
Deleted image.part.03.
...
Deleted image.part.23.
Deleted image.part.24.
Delete Bundle complete.

So, we just killed our AMI. The data is not on a disk anywhere and the whole instance is not recoverable. Seriously. In this case we can redeploy from Maven, but that's annoying. If you are serious about using Amazon (or any other provider) you not only need to set up your own failsafe through S3 and the Elastic Block Store, but also take advantage of whatever backup and recovery procedures you can find.

So, what's the point of all this?

To say this: many applications will most certainly move to the cloud, but they won't be core enterprise infrastructure - at least for several years.

Why? Because the management and packaging of cloud applications need to look similar to the way that developers build, deploy and manage applications already.

And to get there, we need - hey - standardization and less, ahem, "unique" configurations. Only with standardization can the cloud become the chosen deployment option for anything beyond static content.®

Dave Rosenberg is the co-founder and former chief executive of open source enterprise service bus and integration platform MuleSource. Dave is currently working on a new stealth start-up based in San Francisco.