Moving My Blog to the Cloud

A week ago I decided to put my blog where my mouth is. I am writing a book on cloud computing and services, and needed some hands-on experience on the latest technology available. I had tried Amazon Web Services aabout a year ago and wasn’t impressed with their offering; the tools were Java-based and somewhat cumbersome. I was in for a surprise. The main reason: Amazon’s Graphical Management Console.

Amazon now allows users to manage servers using a graphical control panel that allows you to do most tasks using a point and click interface (for a sneak preview of what it does, see this video by Mike Culver, one of Amazon’s Web Services Evangelists).

In this post I will try to explain some of the concepts that you must have in mind if you’re thinking of moving some of your servers to the cloud.

AWS Components
So the first thing you must understand are the components that make up the Amazon Web Services platform and what they can do for you. 

First is the Elastic Compute Cloud, or EC2, which allows you to spawn (and destroy) virtual servers. Each one of these servers are available for the time you need them. If you need to increase the number of servers for a day (because you have a newspaper article coming up the next day), you can just replicate your server a number of times, creating a temporary “server farm”. The day after the article, you can discard half of them or whatever you need. This is what the “elastic” word means. You can stretch or compress your servers as you need, and you only pay for actual hours used, not per server.

How do you “clone” your servers? Amazon uses the concept of AMI or Amazon Machine Image. You can create AMIs for each type of server. For example, you could have a webserver AMI and a database server AMI. The AMI contains the OS, the code and the software necessary to “create” a new server. Once you have an AMI, you can create as much servers as you want from that AMI. Each copy of the server you launch is called an “instance”. This term is borrowed from the Object-oriented world and basically means a copy of the “Object” made from a “Class” (which in this case is the AMI).

One thing to have in mind is that these instances, when deleted, erase the information you have stored in them. This is why Amazon has introduced EBS or “Elastic Block Store” units. Imagine these as swappable hard drives that you can attach or dettach from the instances. These units don’t die (under regular circumstances) and can be backed up easily, using a procedure called “Snapshot”.

Another thing to remember is that these instances have variable public IP’s. Each time you launch a new instance, the IP changes. This might not be good if you have an external DNS manager (like GoDaddy) and have to wait for the IP change to propagate. So Amazon offers “Elastic IP Addresses”, which are static IPs that you can attach or detach to your instances. That way if an instance dies, you can create a new one and attach the IP to it, making it instantly available without having to change your DNS entry.

Last, but not least, you have the Simple Storage Service, which is the unlimited backup storage service, where you will be backing up the AMIs and the EBS snapshots.

My specific setup
The way I thought of having the components work for me was to have the code for the blog and the Mysql data in an EBS drive. Then I would create an instance to connect this EBS drive to and finally have an Elastic IP pointing to the instance.

So I spawned an instance based on the Fedora Core 8 AMI from Amazon. This is a public AMI that has the barebones of the Red Hat based OS.

In order to connect to this server, Amazon generates a password for you in the form of a certificate. You then download this certificate to your computer, and using PuttyGen, convert it so that you can use it with the Putty terminal.

Once I had that, I started adding components I needed using the RPM manager “yum”. I updated all the existing components and added some additional ones I needed.

I then created the EBS and attached it to the instance using “mount”. I edited the /etc/my.cnf to use the EBS directory for the data storage. I did a mysqldump from my old server and also tar’d up the WordPress directory.

I started mysql and then imported the data. Untarred the WP code and edited the httpd.conf file. I updated GoDaddy and in about 15 minutes the blog was up and running on AWS.

The total cost and performance
So far, my blog has run for a week and the total cost has been about $20 dollars. I expect it to run for about $80 for a full month, which was exactly what I was paying on the previous hosting company for a dedicated server.

In terms of perfomance, I can say the blog loads perfectly fine, with an average of 600-700 milliseconds response.

I can honestly say Amazon has done a great job with the Management Console and they promise to bring other services to it, including their SimpleDB and S3. I will be on the lookout for these and also will be reporting on any new developments they bring to their offerings.

I can honestly say I can’t see why someone wouldn’t host their web applications with AWS. With the ease of use and elastic capabilities, it’s a no-brainer for anyone wishing to offer scalable applications.

Tagged as: aws, Blogging, cloud, infrastructure, Scalability, server