The only criticism I have is that they don’t put enough emphasis on one of my key reasons for why it’s suddenly taken off. Cloud computing is not a new idea – it’s an extension of the Utility Computing that John McCarthy talked about in 1961. Although they only make a passing remark in section 3, I think one of the most important reasons it’s taken off is that the services Amazon provide were the first that were not a “solution looking for a problem”. Earlier offerings by the likes of Sun, HP and Intel all created a solution that they tried to sell to clients. The problem was that there were remarkably few problems that their solutions solved. Amazon simply exposed services that they were using internally already. That’s not to say the other reasons they give are not valid, I totally agree with them. I think they just missed a good point.

One of the topics I only glanced over is covered cover quite well in section 6 – Cloud Computing Economics. They provide some interesting example cost calculations. Although the numbers are obviously US centric, they do provide a nice way for a company to approach making the old “build vs buy” comparison.

In summary, I highly recommend this paper for anyone who wants to get the head around what this Cloud stuff is all about and what they need to do to prepare for it.

The Buildix image is now available for public use as ami-e4ca2f8d.

Here’s a couple of tips to keep in mind when rolling your own:

Remeber it’s Xen

I had problems getting my first batch of uploads working on the network. They would boot without a problem, but the networking would not initialize (as I could see from the console output). Things got a lot easier when I started manipulating the image locally using my own Xen installation. By booting it up on my local Xen server I could see where the problems were and fix them with a lot less pain and suffering.

The other benefit you get from testing your image in Xen is that you can bundle the image directly (ec2-bundle-image) instead of having to scrape a running machine (ec2-bundle-vol).

There can’t be only one

As the name implies, EC2 is all about having a big cloud of images. Chances are there will be a lot of instances of each image running out there. This means that the image itself needs to pick up its identity on boot up. Amazon provide a nice RESTful API that can provide each instance with information about itself. The documentation for the meta-data that’s available is available at http://docs.amazonwebservices.com/AWSEC2/2007-08-29/DeveloperGuide/AESDG-chapter-instancedata.html. The stuff I needed the most was the public SSH key to allow to log in as root, and the hostname of the machine. Here’s what I added to /etc/rc.local to allow me to do this:

if [ ! -d /root/.ssh ] ; then
    mkdir -p /root/.ssh
    chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
    cat /tmp/my-key >> /root/.ssh/authorized_keys
    chmod 600 /root/.ssh/authorized_keys
    rm /tmp/my-key
fi

hostname `curl http://169.254.169.254/latest/meta-data/hostname`

The first problem I bumped into was stability. Once I had configured and booted the zones I wanted, I discovered that ssh-keygen would segfault and dump core when run from within a zone. Normal ssh and scp commands would also occasionally segfault as well. After some very light scratching around, I decided to patch the systems to see if that made the problem go away. It did not – so I replaced it with the Sun Freeware OpenSSH package. This is when I found the next problem – patching.

For understandable reasons, Sun have restricted access to patches for Solaris 10. The days of just pulling down the latest recommended patch cluster to sort out your machines have gone. Sun now recommend you use Update Manager, a Java GUI app that registers your machine with Sun, and lists what patches you can download. All sounds reasonable in theory, but the first few times I tried it, it kept on blowing out with a com.sun.cns.authentication.CMDExecutionException. Turns out it’s broken on machines with Zones, and you need to manually download and apply a patch to fix it. Another thing to remember when patching is to make sure that all zones you have configured have been properly initialized, and that you’ve been through the system identifications at first boot.

And then we have the niggles category. There is no lsof package for amd64 Solaris 10 yet, but you can script most of what you need using pfiles and fuser. DTrace only works in the global zone. While the global zone has all the rights it needs to trace what’s going on, if you’re running more than two or three zones trying to find the specific process you’re trying to debug can be a pain.

With all this pain, is it worth it for development and testing? Most definitely! Zones allow you to have all the production-like environments you need for testing, or even just for developers to spike ideas in. Clients are happy because they don’t need to buy so much hardware. Testers are happy because if they need a new environment they can have it in a matter of hours instead of days or weeks. Sys Admins are happy because they don’t have to keep finding rack space for more machines.