Future of deployment: Part 2 - The Image in the Cloud is the new EAR
Last December I wrote my first part on the Future of Deployment explaining the difference between big ol' servers with a gazillion applications and lots of new shiny small servers with each its own application. This time I'm going to go to the cloud or your virtualized servers and give you my vision of how we are going to package and deploy applications in about 3-5 years.
How we used to deploy an application
Well you all know this one by heart: You get your environment up and running, like, install an application server, setup your database, choose a sql script to run against the database, configure resources and deploy the application in the application server. After everything is in place you start the whole bunch and bask in glory!
Does the above deployment scenario apply to virtualized/cloudy environments. Yes it does, of course! The environment setup is greatly simplified, using stuff like AMIs or virtual images aka appliances 😉 you get your database or application server out of the box but configuring and installing the application and configuration/resources is still the same old boring cumbersome task.
Taking 'it' all the way to the top
If you look at a lot of the current images out there, they are basically just an Operating System which you can instantiate. Some of the vendors, like Oracle have images that also contain an installed database on top of an OS, like a favorite flavor of Linux. But imagine that you can bundle up your own application with an image which then becomes your own Virtual Appliance. You use your own virtual appliance, (OS + installed application + config files) to set up your environment quickly and voila! no more boring installing application server/database, deploying application per environment.
Sounds too good to be true eh?! In this day and age it unfortunately is.
The 'biggest' problem
It's the size of the virtual image.
Lets say you have created a new release of your application. In total, War + config files + some DDL scripts is about 100MB, not a big deal indeed! Easy to copy across to different environments. Now try and create a virtual image of this release.
Step 1, get image (= 2GB big, OS + installed Application server + installed DB)
Step 2, Install your application on the virtual image (+= 100MB)
Step 3, Prepare image and pack it up.
Total size of your package or if you like bundle (os + appserver + db + app = 2100MB). Try converting and copying your VMWare 2.1GB to Amazon EC2 over the internet! It will take a while and those are a lot of cups of coffee before you can get it up and running. For the smarter persons out there, just use the AMIs already on Amazon and re-bundle which solves the problem :).
Too simple for you?
So who puts their database on the same virtual server? Nobody, or at least nobody serious 😉 Well for these folks you can create a second virtual image with the database and package that with your application image. Now you have 2 images that can be used together, but yet again more uploading and perhaps more disk space to waste.
And what about resources you need to connect to which you can't package up with your images, like a corporate LDAP or even worse a mainframe system which needs to be accessed via MQSeries and a Message Broker? Well here it still becomes clear that after creating images and instantiating them in environment there are still sometimes activities needed, like for example configuring JMS resources to connect to a remote Queue Manager, to make your application fully-up-and-running-functional. So in a lot of cases we still need automated deployment to get it all going. And while we're at it, you can have a sneek peek at our Deployit 1.3-Beta which already is beginning to get some of these packaging concepts, like Deployment Package with, Queues, Datasources etc...
Still it's a nice picture to draw…aka the image is the new EAR
Packaging/bundling up your application with an OS and delivering it as your release. You get to do almost whatever you want to do on that image, whatever is best for YOUR application. Tune not only the application server, but even the OS! Use whatever libraries you want. The sky is the limit! 😉 or at least what sysadmins will tolerate.
This is IMHO, the biggest plus! You get to deliver something which is very, very close to the production setup. This will eliminate or greatly reduce runtime and configuration issues which you may face when getting your application running in production.
In part three, I'll have a look at where the virtualization/cloud vendors, like IBM, Oracle, VMWare (+ Spring, anyone?) are now. How you can start moving from just delivering a war/ear to delivering virtual images/appliances tomorrow (and not in 3-5 years 😉 )