Someone asked me what actually was cloud computing, and I found it rather difficult to answer concisely and coherently.  Much arm waving was involved, and comments like “you know, like Amazon”, and “you get billed for your usage”.  I thought it was worth looking at a clear, simple definition!

What is cloud computing?

Cloud computing is

“a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

according to the National Institute of Standards and technology.  Thats fine, and the more technical among us could probably leave it at that.  How would you try describing cloud computing to your CEO, though?

Cloud computing can be thought of as a way of pooling the resources of a number of computers together, and then pouring those resources into whatever applications you decide to run on the top of them in a very simple way, allowing you to set up new applications very quickly and easily.  Instead of having to build a new server for a new application, you can pour some more resource from the cloud for it.  If the resources in the cloud are running low, just add some more servers to the pool.

In the past, there have been a variety of mechanisms that do parts of this, but haven’t applied it all together. 

Older, similar technologies

Clustering computers has been done for some time.  This allows computers running a application to work together, providing redundancy for the application, and generally some performance improvement.  How does this differ from a cloud?  Well, a cluster was generally quite complex to set up, and only really focussed on a single application.  You couldn’t pour resources from all the machines into a new application quickly at all.

Web farms can support many web applications, running over lots of web servers.  How does this differ from a cloud?  Well, web farms again tended to be hard to configure, and it was very difficult to apply specific levels of resources to specific web sites – if one web application used lots of processing power, the others could start to run more slowly.  Administration and maintenance to balance these problems, and to roll out new applications were often complex.

Virtual server providers are almost like mini clouds, where running virtual machines are provisioned simply and easily across the available hardware.  How do they differ from cloud computing?  Well, cloud computing separates off storage and processing power, allowing you to apply more storage or more processing power as needed to any application running on the infrastructure.  It adds another level of abstraction, which allows much more effective (and quick and easy) application of the necessary storage space and processing power from all the resources pooled in the cloud, rather than limiting it to a single virtual server, which can then be quiite complex to change.

All of these technologies really combine to provide a simple infrastructure on top of a pool of servers – you have the performance and resilence of a cluster, without the headaches of setting it up, and without the limitations of the focus on a single application.  You have the distibution of a web farm, allowing multiple applications to share resources, but with much easier tools to support rolling out new applications or providing additional resources to underperforming ones.  You have the benefits of virtual servers, but with better applications of storage space and processing power to your actual applications.

Confusing technologies and terms

There are two points that many people don’t quite understand about cloud computing, even if they grasp how it can be applied.  These are:

Does a cloud have to be on the Internet?

No!  A cloud can be run inside a private corporation, or even at home if you have the resources.   Ubuntu provide cloud deployment and management tools as part of their open source enterprise servers.   The reason cloud computing is synonomous with the internet in people’s minds is that the real benefits of cloud computing require massive, massive deployments of hardware to see the real benefits and cost savings.  Having said that, even a small cloud might be better for supporting a slew of internal web applications than 15 individual servers.

Because of the costs of a large cloud, only companies like Amazon have successfully deployed them as yet.  They use clouds to sell processing power and storage space to any one who wants to buy them.

Will I be charged by processing use or storage space?

This is actually a separate concept, called Utility computing, where you are charged for your system use like you are charged for gas, or electricity, hence the name.  This is by no means integral to the concept of cloud computing – though Amazon EC2, the biggest cloud deployment, does use this model to charge for access.  It doesn’t mean every has to charge this way, and an internal corporate cloud would just cost electrical consumption, hardware and licensing.

Don’t confuse the two – utility computing is a model of charging for computer use and storage space, while cloud computing is an infrastructure for pooling computer resources to be poured simply into applications on demand.  They may both be used at the same time, but aren’t the same thing.

Just a quick sneaky trick – if you’re used to being able to run terminals as root, or you need to run a lot of commands as root, and are sick of having to type sudo every time, there is a sneaky way of increasing your privileges for the terminal sessions. 

Open a terminal, and run:

sudo su

and you have a terminal running as root!  running su by itself doesn’t work with Ubuntu … but if you sudo the command, it does.  Generally, this isn’t great practise – its too easy to make a mistake and damage the system, so use with caution!

Setting the hostname on an Ubuntu linux installation is pretty easy during the installation.  However, for a standard image to be dropped onto a wide range of machines, it really needs to be unique and set via a script.

We like to use the serial number of the PC in question, though this is more or less practical depending on the brand of PC.  Acer, for example, tend to have VERY long serial numbers – it may be unique, but its going to be harder to type than just an IP address.  IBM tend to use reasonable 7 digit strings, which is is much more usable.  Other brands can be longer or shorter.

Setting hostname itself seems easy – just run

hostname <newname>

(where sudo is used to run the command as root) in a terminal, and the hostname of the machine will change.  You’d think we were done, but unfortunately not!  This will only change the hostname until the next reboot.  On startup, the contents of the file

/etc/hostname

is used to set the  hostname.  To update this, I like to set the hostname for the current sessions, then run

hostname > /etc/hostname

(as root) which willoverwrite the file with the current hostname.  If running as part of a script on startup, this will set the hostname now, then update the file for future restarts.  However, we still aren’t done.  We need to update another file

/etc/hosts

with the details of the name for networking purposes.  We need to add the hostname, and any domain name aliases too.  The hosts file will probably look something like:

127.0.0.1                        localhost                 localhost.domain.local

127.0.1.1                        <hostname>

Update the hostname line, and add new aliases for the hostname for any domains that may be relevant.  At this point, the system is renamed!  However, this is all still pretty manual – ideally we need to script the process.

Now, to get the serial number, we can query the bios using the dmidecode command, and then process it usign the myriad of linux text handling commands.

dmidecode | grep “Serial Number” | head -n1 | sed -e ‘s/\tSerial Number: //g’

(as root, again) should return the serial number from the bios!  We can combine this with the hostname command, as follows:

hostname $(dmidecode | grep “Serial Number” | head -n1 | sed -e ‘s/\tSerial Number: //g’)

(once again, as root.) This will set the hostname to the serial number.

I actually combine all of the commands discussed to form a single script -

hostname $(dmidecode | grep “Serial Number” | head -n1 | sed -e ‘s/\tSerial Number: //g’)

hostname > /etc/hostname

echo “127.0.0.1       localhost     localhost.domain.local” > /etc/hosts.new

echo “127.0.1.1     ”$hostname”     “$hostname”.domain.local” >> /etc/hosts.new

mv /etc/hosts.new .etc/hosts

This sets the hostname, then updates the hostname file.  It then generates a complete hosts file line by line, and overwrites the old version.  There are probably better ways of updating the text file directly, but this works effectively enough.

Finally, I set this script file (which I named hostname.sh) to run on system startup.  Simply copy the file to

/etc/init.d

and run (as root)

update-rc.d hostname.sh defaults

where hostname.sh is the chosen name for your script.  This will add the script to the startup scripts on the machine, where it will automatically be run as root.

Recently, I’ve been playing with Linux, specifically Ubuntu, in an attempt to set up a simple, maintainable client for virtual desktops.  Its been a fair while since I’ve used linux in a serious sense, so I thought I’d post up what I’ve done, as I progress (largely for my own reference, but hopefully others might find it of use!)

Key requirements are:

A virtual client!  In this instance, the vmware open client will need to be installed and configured on the desktop.  There are still limitations with the open client that may break the plan – limitations with remote media playback, and usb redirection are two areas in particular that may cause issues.

A working web browser!  Of course, Firefox is an obvious standard, installed with Ubuntu, so thats not much of a challenge, at least on the surface.  Beyond a working web browser, we need to possibly extend our server architecture to support browsers beyond Internet Explorer for our key wep applications, allowing a level of work to be carried out in the event of virtual desktop failures.  This is where things get a lot harder!

A standard environment across different hardware, locked down for the default user.   This is actually quite tricky.  By default, linux is designed to be easy to customise and configure, so locking it down to a single user, while allowing network proxy changes and wireless connections, is actually quite a challenge.  In addition, desktop launchers will need to be variable, depending on local printer installations for users on laptops with home printer (vmware-view allows you to redirect a printer, but you need to specifically do it by name).

An architecture to allow remote reconfiguration, support and updates across a company wide platform.  This is one of the worst areas – linux still lags quite badly behind the sort of architecture taken for granted on a Windows network when it comes to administration through global policies.  It’s still fundamentally a server operating system,and admin tools generally focus on supporting machines runnign in that capacity, not as clients.  This is the hardest area of all, looking forward to a possible roll out of well over a thousand machines world wide, with a technical team with no linux experience!  Keeping the client simple and cheap, allowing machines to be swapped instead of supported is a very high priority where possible.

Hopefully the next series of posts on this topic will be useful, although its quite a change of tack from SharePoint!  Don’t worry, as new SharePoint issues come up, I’ll still be posting on that topic too.