The web dev’s intro to the cloud (part 1)

This article first appeared in issue 219 of .net magazine - the world's best-selling magazine for web designers and developers.

You can’t move these days for the word “cloud”. It seems to appear in every marketing slogan or new application. But is it just a buzzword, or is there real magic behind the buzz?

In this four-part series, we’re going to look at how you can use the cloud services on offer to provide your hosting, improve your site and generally make your life better.

Doing cloud hosting is both easy and devilishly difficult. Just like everyone can design and build websites but some people create awe-inspiring sites, not all cloud hosting is created the same.

At the moment, there’s more hype around cloud hosting than there is adoption, so why should you adopt it now? Very briefly: because it gives you everything that dedicated hosting does and elements of the cloud hosting ecosystem, because there’s more to it than just virtual machines.

Head in the clouds

First, what is cloud hosting? It sounds like a simple question, but depending on who you ask, you’ll get a different answer. Entire blogs are filled with arguments over the difference between the cloud and service-oriented architecture (SOA), for example. Does it have to be multi-tenant? Does the hardware have to be shared? At times, the debate around these issues verges on holy war, so it’s virtually impossible to give an all-encompassing definition that everyone will be happy with.

However, there are a few important things that we can agree hosting has to have to earn the term ‘cloud’:

1. The hardware is abstracted If some hardware dies, the hosting company assigns some new hardware to it and the whole swapping process is handled for you.
2. A good API Everything has an API these days. Entire hackdays are dedicated to mashing together servers with APIs. Cloud hosting APIs mean you can start and stop services as you need them and that means you can script it.
3. It’s pay-as-you-go Innovation loves cheap. If it’s cheap and easy to try something, what have you got to lose? (And it’s very cheap to start up virtual instances: a few cents up to a few dollars.)

To sum up, when I say ‘cloud hosting’, I mean it has to take advantage of the features of the cloud so it can scale, be redundant and change its configuration as the app’s requirements change. It can’t just be virtual or on-demand hosting.

Not everything involved in getting sites hosted on the cloud is new. Much of it has been done by system admins running at a much larger scale for years. But cloud hosting means that it makes sense to learn some new skills ... so let’s get started.

Which clouds?

Raise your hand if you’ve signed up to Amazon’s EC2 or other cloud hosting solution, fired up an instance and got something running. Whenever I ask this at an event, around half of the people put their hands up. Many have fired up cloud servers, tried stuff out ... and then gone back to their trusty dedicated boxes wondering what the fuss is about. Don’t be disheartened by a bad experience: not all providers give you the same thing.

Each cloud provider tends to focus on a key value. Some offer great support and management solutions. With these, you can start your instances and have them managed much as if they were dedicated machines. This might be appealing to anyone who likes that level of support on their servers. A good UI lends itself to less experienced sysadmins, but may not provide all of the functionality of other management UIs, such as Amazon Web Services (AWS).

Amazon offers support for $100 a month but by default there’s no direct technical support. Its unique selling proposition (USP), for me, is the amazing number of services it has, which are released at a staggering rate. Amazon’s services, which we’ll look at in this series, cover hosting, load balancing, scaling rules, email, messaging and the more esoteric Mechanical Turk.

If you spend some time understanding that transience is good – that is, if you allow for things falling over then your app will work better – then something such as SpotCloud will make your eyes light up.

SpotCloud provides aggregated cloud hosting across multiple data-centres from many providers around the world. If you can build your app so that almost any part of it could run anywhere, you can benefit from very low costs and extremely high availability.

Cloud hosting providers don’t have like-for-like services that dedicated hosting providers have, so it’s worth shopping around or working with someone who’s used one for a while. At my company, 3EV, we use AWS and some others all mashed together, which marketing guys might call a multi-provider cloud.

Booting clouds

Before we go any further, let’s look at a brief example of how you go about this stuff in practice. To launch an EC2 instance with Amazon, sign up from aws.amazon.com. Once signed up, log into the AWS console via aws.amazon.com/console and navigate to the EC2 tab.

Once here, you’re ready to launch your first instance. Do this by hitting the Launch Instance button from the dashboard and then click the first option in the quick start list of images. There are hundreds of AMIs available. Each image provides an operating system, applications and config for everything from a Windows desktop and an Oracle database to a good old LAMP stack. We’ll be sticking with the LAMP stack, but have a look around the AMI list.

The next screen enables you to select the number of instances and the size. If you’ve just signed up, use the micro as you can get this pretty much free. The screen after has several options, the most interesting of which is the User Data, because if you use Ubuntu you can pass magic commands to it that it’ll execute on boot up. We’ll explore this later in the series, but the gist is: you pass it stuff here and it does things when it starts. Have a look at help.ubuntu.com/community/CloudInit if you’re as impatient as you should be.

Next comes tags. The time it takes to launch cloud instances on AWS gives you an idea of the richness of the functionality, but it’s worth pushing on through. For now, click Continue and on the next screen Create a new key pair. Give it a name and select Create & download your key pair. You’ll need this later. Click Continue again.

On the next screen, select the default security group and, finally, click Launch. When you’ve closed the window you’ll see the instance plodding away through ‘pending’ until it’s ‘running’.

To SSH onto it you use the key you downloaded a few steps earlier, called something.pem, and the domain of the new instance, which you can find from selecting it in the list:

ssh -i path/to/the-key.pem ec2-user@ec2-11-11-11- 11.compute-1.amazonaws.com

That’s it ... a cloud instance running in some part of Amazon’s infrastructure. Don’t forget to terminate the instance, because you’re being charged for it as long as it’s running.

If starting instances and getting onto them is so easy, what do you need to learn?

Well, cloud hosting introduces a major change to hosting. Things move around and they need managing because your server isn’t a big fat beast on floor two of the data-centre; it’s a combination of services that need to work in concert. This is where the cloud management layer comes in.

Anyone used to managing large data centres or virtualised machines will find this more familiar, but with the cloud you need this for even the smallest number of servers, because you want to be able to manage how the servers behave in different circumstances.

What happens when the DB dies? What happens when the database is running at zero per cent for three hours ... should you scale down to save money and the environment? You can do this manually, or you can use tools such as Scalr and RightScale, which provide cloud management.

Let’s take a quick tour around the former. You can sign up for a dev account with Scalr and start creating complex cloud configurations in just a few minutes. Sign up at scalr.net/order and begin making your account. Once logged in, start building your first farm from the menu at the top, then add your first role. Scalr, RightScale and most other cloud management systems work through the concept of roles. Each role does something specific: it’s a database, a web server, a proxy or a worker. You can have as many roles as you like and you should get into the habit of breaking your app into as many small roles as possible. But more on that later.

A typical hosting setup would start with web, DB and proxy, each of which is a role. To create a role you can use the role builder via the Roles menu item, or you can do it manually.

As with any cloud instance, you begin with the machine image, where it should start – on Rackspace, AWS, OVH, GoGrid and so on – and what size it should be. I suggest that you stick to the smaller-sized images to start with because these cost only a dollar or so a day, whereas the Quadruple Extra Large is going to set you back $2 (about £1.20) an hour. It adds up quickly.

Scalr, RightScale and other cloud management platforms run scripts at particular instance events – when it starts, stops, changes IP and so on – which enables the instances to self-configure by installing software, downloading your app and generally doing everything that you’d have to do if someone thrust a shiny new server in your hands.

For example, if you wanted to get a basic site installed from a Git repository you could use the Ubuntu WordPress installation, taken straight from help.ubuntu.com/community/WordPress:

sudo apt-get install wordpress php5-gd
sudo ln -s /usr/share/wordpress /var/www/ wordpress
sudo bash /usr/share/doc/wordpress/examples/ setup-mysql -n wordpress localhost
sudo bash /usr/share/doc/wordpress/examples/ setup-mysql -n wordpress wordpress.mydomain. org
sudo /etc/init.d/apache2 restart

A rule of thumb is: if you’re doing it for the second time, you should have written a script.

Configuration management

The script leads us nicely on to the next aspect of cloud computing: configuration management. This is very unglamorous – it’s close to change control and other such dull maintenance tasks. But it’s one of the secrets of cloud hosting; it’s what makes things happen by themselves.

As we saw with Scalr, a simple script can turn a vanilla instance into a working app in just a few lines. Imagine that at the scale of tens or hundreds of instances and you’re close to what a solid cloud architecture feels like. Instances fail or instances scale, and when they do the configuration management picks up the task of getting them set up.

Configuration management deals with everything from the OS up to your app, what version of Apache, MySQL and WordPress and how everything should be configured. This is what changes a server crash from something to worry about to something you don’t care about. When a dedicated server crashes, you revert to a backup. When a manually configured cloud instance crashes, you might use a backup or recover by hand. But when an automatically configured server crashes, it self-configures. It comes back by itself.

Config management systems such as Puppet and Chef run on the basis of recipes, or small scripts that install and configure the required software much like the script we saw in Scalr. The difference we’ve found is that these feel more comfortable working across many types of server and cloud, because they’re just built to configure.

You can combine these to build up complex configurations quickly. Suppose you have a recipe for installing your versioning software (which I trust is Git), another that installs your favourite server software, one more that brings in your application and another that runs monitoring software. Each of these recipes can be written separately in small, easily understood scripts that are combined by Chef.

The magic of configuration management is when you can combine several roles into one. Suppose you find that you run a report every night and you update your prices at the same time. These might run on separate servers for a while, but if they’re set up in config management you can mash them together and halve the price of the servers you’re paying for. Bargain.

Config management is often the trickiest part of getting an app running natively in the cloud. Servers have to relaunch repeatedly, never failing, and this takes time to perfect. It shouldn’t be shied away from because this is what makes complex server setups manageable.

We’ve seen an uplift in people wanting to use cloud computing. They ask us about getting the cloud servers configured and how the app will stay up, but configuring the servers isn’t something that comes to mind. We wrote scripts to help us do this, which show us what’s actually installed on existing dedicated servers and get it into the config management. This housekeeping technology very quickly makes the cloud make sense. Have a look at Chef, at wiki.opscode.com/display/chef/Recipes.

The important parts of the ecosystem that I’ve outlined here are essential to a good, solid cloud architecture, but they’re often missed by people starting out. Running your hosting on the cloud requires more than just a few EC2 instances or an account with GoGrid. Like everything, it involves some careful planning and some trial and error, which can be done quite cheaply thanks to the pay-as-you-go model.

Work out the best way for you to configure your instances, given your expertise at scripting. Scalr is just one example of managing the cloud for you, so don’t be afraid of trying something homespun. More on that in part two, where we look at how some of the more complex features of cloud hosting can help improve your site’s performance.

Where next?

Getting started with the cloud isn’t as scary as you might think. For instance, Amazon’s signup starts at aws.amazon.com and takes 20 minutes until you’re launching instances.

Signing up for most other cloud hosting package will usually be just as painless and should take no more than 20 minutes.

You can try out Amazon’s services for as little as an hour, which is often the best way to understand what they really offer. Seeing Amazon’s relational database service (RDS) instance running for the first time makes you realise you’ll never have to configure another MySQL server again.

To get cloud management started, create an account with Scalr or RightScale, punch in your AWS details and start configuring your farm. If you start at this level, you’ll probably understand better how the cloud should be configured.

RightScale is pricier, but provides more features, although Scalr is sufficient for most initial cloud projects and will certainly be enough for prototyping your ideas.

To learn more about configuration management, start with either Chef or Puppet. These take more learning than the previous systems, as they’re more generic and require breaking your server and application configuration down into little pieces, but they’re worth it.

Once you’ve tried a few of these routes, or if you think you would rather not do the configuration for production yourself, find a cloud consultant.

It’s important to locate consultants that have done it before; it’s easy to boot cloud instances, but it takes experience to get it right. Amazon runs a partner program, which we’re part of at 3EV.

Proud sponsors of our special cloud series

Why choose OVH?

Immediately accessible resources, full hardware availability, flexible infrastructures... With cloud computing, OVH has created the future of internet hosting. Companies get secure and reliable solutions at their fingertips that are closely aligned to their economic and structural needs. In minutes, you can now have the use of a real datacentre or benefit from flexible hosting. Reliability is second to none, with an availability rate of 99.99%.

To guarantee these results, OVH hasn’t had to compromise its infrastructure – in fact, all physical resources are doubled, whether they’re servers, storage spaces or network hardware. Nor has it affected prices, which are some of the lowest on the market. Visit ovh.co.uk or call 020 7357 6616 for details.