Original URL: https://www.theregister.com/2008/10/17/cloudy_java/
Java in the cloud: hardware-free miracle drug?
Cross platform hits its limits
Posted in Software, 17th October 2008 14:02 GMT
Despite huge spending and a never ending supply of new products, enterprise IT is no less complicated than it was a few years ago. Cloud computing with all of its promises is still more of an aspirin for your headache than a cure for your infrastructure disease.
The cloud is still relatively virgin territory with effectively two vendors - Amazon and Google - setting the pace and defining the way people think about it. Despite announcements and press releases, we've yet to see much from IBM, Sun Microsystems, or Microsoft, the vendors who typically drive new technology purchasing. And there isn't much consensus on what defines a cloud, with only two consistent themes of multi-tenancy and infinite scale.
While it's easy to consume cloud resources, deployment is defined by two approaches: virtual machine images like Amazon EC2 (known as Amazon Machine Images or AMI), and direct code deployment like Google App Engine. App Engine only offers support for Python applications and is therefore severely limited. Before everyone starts crying, there is nothing wrong with Python, but odds are you will need support for more than just language in or out of the enterprise.
Despite lacking multiple programming languages, the Google approach of code and deploy is far more appealing and I would expect that mechanism to become the weapon of choice for most, if not all cloud offerings, regardless of language.
Java, which introduced the (theoretical) "write once, run anywhere" paradigm seems like the most likely candidate for a cloud operating system standard, but Sun has been mum on this as they've reorganized and finally created a cloud business unit.
One of the big challenges for Java in the cloud is that no one has yet come up with a simple deployment mechanism. Several people have argued with me that this approach wouldn't be applicable in most scenarios and in fact might not work at all in light of the need for things like build and compile. Nonetheless, that doesn't mean that Java shouldn't become the dominant cloud operating system.
Questions answered
In fact, Java answers many of the cloud question: Java is open source, mature, standardized, has plenty of development and management tools, and APIs that support a vast array of other systems. Java also has a very large enterprise developer base, a key to getting new technology tested and adopted.
Deploying an application at a cloud provider may be similar to an enterprise or local deployment but the methods developers use to interface inside the firewall versus the cloud are very different. Developers have to change the way they manage and deploy applications to jive with the cloud providers' unique infrastructure. And since we currently lack portability between virtual-machine (VM) vendors and not all cloud providers instantiate the same rules and interaction mechanics you are pretty much locked in.
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.