Live action case study: SOA governance in the cloud

There aren't yet many practical demonstrations of how you actually use cloud services like Amazon's Elastic Compute Cloud, or EC2. To put my money where my mouth is, I coerced Kevin, my IT guy, into setting up and deploying one of our products on Amazon EC2.

Disclosure: Lest you think I am trying to shill, we obviously used our own software for this proof of concept. Mule Galaxy is a service-oriented architecture governance platform with built-in registry and repository. It's written in Java and is GPLv2 licensed.

We are using the EC2 instance of Galaxy for customer demo purposes and to prove out the cloud as a deployment option. Odds are most enterprises won't put their SOA governance in the cloud, though there is a strong likelihood that you will have assets that cross your corporate firewall.

The cloud is becoming a more and more realistic deployment option making software consumable in new and interesting ways.

Just how complicated is this cloud thing?

The Amazon toolset has come a long way since the beta launched. In fact, it took us less than an hour to provision a lightweight instance of Fedora 6, install a few missing utilities, set a couple of environment variables, and launch Galaxy.

Here are the basic steps, followed by the nitty-gritty details for each section:

1. Install and configure ElasticFox, an EC2 plugin for Firefox (10 minutes).
2. Pick an existing EC2 AMI to boot. Selected a lightweight install of Fedora 6 (10 minutes).
3. SSH into the machine and install prerequisites via yum and rpm (20 minutes).
4. Set environment variables such as PATH and JAVA_HOME (10 minutes).
5. Download and launch the Galaxy EE Stand-Alone jar (10 minutes).

If we were to package this up as a product, offering all of these things could be scripted and made into a one-click install.

Step 1
ElasticFox is a plugin for Firefox that allows you to easily provision and manage EC2 instances. We provided ElasticFox with all my private Amazon details such as my account ID, AWS access key, and AWS secret key. Next, we created a keypair that allows me to SSH into the box without knowing the root password of the instance. Finally, we created a security group that enabled two services that we're going to need--SSH and HTTP.

Step 2
We selected an Amazon Machine Image to run our server. We chose ami-78b15411, which is known as marcins_cool_public_images/ fedora-core-6. I found this image by sorting the public AMI's by rating and then combing through the list for something lightweight and mainstream. You can find the list here. We could have also grabbed an Elastic Server from CohesiveFT but we went down this path for a less informed experience.

Step 3
The Fedora instance that we got on EC2 is very basic, so we have to grab some additional components. I know that we can get RHEL on there but, again, we were trying to go for the less informed approach. After all, a little knowledge can kill you. So, we SSH into the Fedora instance and install the missing utilities and programs.

Components we need to run Galaxy on EC2:
galaxy-ee-web-standalone-1.0.jar--(enterprise version of Galaxy)
apache-maven-2.0.9-bin.tar.bz2--(Maven repository for artifacts)
jdk-6u7-linux-i586.rpm--(Java JDK)
wget--(file transfer utility)
vim--(text editor)
tar, bzip2, unzip, zip--(compression utilities)

Odds are if you were installing locally you would have some of the aforementioned items already. We had to take this step since our Linux install was "clean."

Again, note that if we were making this a product and not a test we would script these things to grab all the necessary components. At this point, Kevin had finished the Snickers I bribed him with and was asking for a Coke. Sadly for him, I am just not that generous.

Step 4
Now we have to place a few important variables into the Linux environment so that my shell knows where to look for the Java and Maven programs.

> export PATH=/usr/local/apache-maven-2.0.x/bin:/usr/java/jdk1.6.0_07/bin:$PATH
> export JAVA_HOME=/usr/java/jdk1.6.0_07

I took a series of Java classes (no pun intended) back in 2000 (the dot.com boom meant we all had to become better people) and to this day I am annoyed by setting the PATH. It just never made sense to me why this wouldn't automatically be set. I never understood why I always had to add things to my path in Unix either. This is why I became a business jerk. Now I can obsess about shareholder value, synergies, and ROI.

Step 5
The final step is to launch the Galaxy Java application, wrapping it in the 'nohup' command so that it will continue to run even after I exit my shell--

>nohup java -Xmx128m -jar galaxy-ee-web-standalone-1.0.jar >out.galaxy &; tail -f out.galaxy

After giving the process a minute to start up, I fired up my Web browser and attempted to connect to the public DNS name of my instance. Success!

Cleverly cloudy
Overall, the process to set up Galaxy on EC2 was just as easy as setting up on an internal server.

But the cloud may or may not be the right answer for tools like this. For example, we don't care about backups, and security is a non-issue. If you were storing special docs or WSDLs or other materials that you were concerned about, you would want to take more care. For demo purposes, this is just fine.

One cool thing we figured out in this experiment is that you could easily use Galaxy to create a federated SOA governance policy by sticking instances both in your enterprise and in the cloud and letting them sync up securely.

Technical note: The commands are examples and may suffer from some poor formatting.