Servers in the Cloud

Culture change for the management of servers.

I have been digging a little deeper into the way Servers are managed in the Amazon Cloud. To convey where I think this will lead IT (both in and out of the cloud) lets take a look at the history.

• In the early days a server was built using the Vendors media and with luck a document to tell you what to select so it was relatively consistent. (Oh Joy: I remember building a server with floppy disks).
• Then along came scripted automation or imaging and a raft of tools to help manage the ‘build’.
• Virtualisation started to drive the creation of templates, just copy the template then personalise it (unique name etc), patch it as the template may not be bang up to date, install any applications and off you go.

So what happens in the Cloud?

Essentially the concept of a Template is where we are at, except with one major difference. When you turn off the machine any changes you made disappear. This is by design and I think this concept will become closer to mainstream ouside the cloud.

Why?

1. When you turn off a machine in the Virtualised world you release compute capability but not the storage. That’s inefficient.
2. In the cloud world when you turn off the machine your footprint is zero, and zero means no costs.
3. It drives a separation of servers, applications and most importantly data, the machine must be stateless or you will lose it.
4. Platform testing becomes a breeze, just test the change on your templates and roll it out to a small number of templates instead of a huge amount of servers.  The servers will get the change when they are restarted (note I say restarted not rebooted, subtle difference – a reboot will retain state where a stop and start will start afresh from template).
5. Automation becomes mandatory, you simply must be able to configure the server automatically and as such in the event of a server problem you just restart it.
6. Backups of servers as we know them become redundant – the automation engine needs to restore the configuration and your data should be tucked up somewhere else (and backed up of course).

Problems ahead?

1. I am certain that some applications will not deal well with the dynamic nature of servers coming and going. Applications that deploy agents and have a database of servers will be a challenge.
2. Some applications just wont work, Active Directory as an example while able to handle servers being built and removed will not be at all happy if domain controllers come and go.