This post started with me rebuilding my blog in a cloudier way, but led me to think about what "Cloud" actually means.

I've heard several different ways of explaining cloud. The simplest is:

There is no cloud, it's just someone else's computer"

Some people think that cloud is anything outside your office or home. Others seem to treat it as a marketing term for whatever they have difficulty selling. I think that cloud is more than that; it's a collection of ideas and practices that have become dominant in deploying modern applications.

The explanation that best sums up "cloud" for me is:

In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.[1]

But what else is there to it? Real cloud means scale. But scale is hard to achieve when your needs, or your budget, are small. So what does cloud mean for those people?

We should be embracing the thinking of proper cloud, even if we don't have the scale to fully deploy. If someone else has built a service that can make our offering more cloudy (with less work) we should embrace that too!

So what practices can we use to achieve the 'cattle' design?

  1. Use virtualization. VMs are far easier to deploy, manage, rebuild and destroy than tin boxes
  2. Use configuration management. Individual configuration is for pets; cattle shouldn't have any visible difference that sets them apart from the herd
  3. Use containerisation. Containers are even more deployable than VMs
  4. If you don't have the scale to make something cloudy, but someone else offers a service for it: use that service!
  5. Make your instances specific. Don't rely on a single instance to run multiple components
  6. Be smart about where you introduce redundancy. There's no point having high availability at the hypervisor when your instances are stateless, and you can just spin up a new one somewhere else whenever one fails

I'm going to be following this post up with a post on how I deployed this blog, that should demonstrate some of these ideas.

  1. Randy Bias ↩︎