ISO27001:2013
Certified Supplier

FIND OUT MORE

We're an ISO27001:2013 Certified Supplier

blog-post-featured-image

Thanks largely to Amazon Web Services (AWS), “cloud computing” has grown hugely in popularity over the past few years. There is no doubt that it has a valuable role to play in today’s business, but equally it isn’t the panacea that it’s sometimes made out to be.

There’s a danger of being seduced by the marketing, as always. We see estate agent signs outside a property that declare that another house has been “successfully sold”, and that makes the agent seem somehow better than one that can merely claim to have “sold” a house. In the same way, “cloud computing” can be positioned as something worthwhile in its own right, whereas in reality it is one of a possible range of solutions to a problem.

Why Cloud Computing?

Some of the reasons cited for using cloud computing include:

  • Pricing: it’s cheaper than traditional hardware
  • Stability: it’s more resilient than traditional hardware
  • It’s more scalable than traditional hardware
  • No need for capital expenditure
  • It’s sexy

Let’s ignore the last one, despite the fact that it’s probably responsible for many smaller cloud deployments. As for the rest, there’s some truth mixed in with misconceptions.

It’s cheaper: under some circumstances that is true. The comparison is anything but simple, though: whereas one or two servers may fulfil the role with traditional hardware, in a cloud infrastructure there will be many servers, load balancers, maybe database instances, firewall services and so on. Each attracts a deceptively low cost – a mid-range server might be $0.40 per hour, which doesn’t sound much. Multiply by 8760 – the number of hours in almost 75% of years – and you have an annual bill of over $3,500. Still a lot cheaper than traditional hardware – but that’s just one instance. We’ll need more, as we will see.

It’s more resilient: it can be. A well-configured cloud infrastructure can handle failures seamlessly. On a well-configured High Availability traditional hardware infrastructure, you’re likely to see some seconds of downtime if a hardware element fails.

It’s more scalable: true. This is – again, for a well-configured cloud infrastructure – a clear advantage. If you have a workload that dramatically scales up at certain times, a cloud solution should be a consideration.

No need for capital expenditure: true. There are many solutions that do not need CapEx, and cloud computing is one of them.

But how does cloud computing differ from traditional hardware?

How Not To Do It

The idea of cloud computing is that there is a shared resource of computing power, and you can rent a server, called an instance, to run whatever software you want. Each one of those instances is a standalone compute server. There will be other components as well, such as firewalls, database services and so on, but let’s focus on the compute instance for now.

You could set up a cloud compute instance and configure it like the server you currently have. You could install, say, a database and a web server, and build yourself a so-called LAMP stack server (Linux, Apache, MySQL, PHP, suitable for hosting a typical business website). What could possible go wrong? Quite a lot, it turns out.

Cattle Versus Pets

It’s helpful to consider the fundamental difference in approach between a hardware infrastructure and a cloud infrastructure.

With hardware, we try to make it resilient. We do that with dual power supplies and storage arrays that include redundant and hot spare disks, and we cover most remaining eventualities by having a cluster of highly-available systems. We also build up our systems over time, installing software in layers, adding a new editor when Susan starts, a new analytics package after James read that blog article, and so on.

In cloud computing land, we don’t build in resilience at the instance level. We engineer the instances to be disposable. If one fails, we start another: simple. That means that the image we boot from has everything installed. When Susan starts and wants to use her favourite editor, we build a new image. When James reads that blog and wants to use some new software, we build a new image. And to make those new images active, we reboot all our compute instances in turn.

We treat our hardware servers as pets, tending them over their lifetime, helping them fulfil their role until they finally check out for the last time. We treat our cloud instances as cattle: if they get sick or no longer meet our needs, we terminate them and get another.

How To Approach Cloud Computing

Below are some considerations regarding the use of cloud computing. This is not an exhaustive, definitive list of actions to implement cloud computing; rather, it is a checklist of things to think about.

  • Start by listing your requirements. In many ways, this can be the hardest part: avoid specifying how something must be achieved, only that it must be. Wrong: two servers will be needed for resilience. Better: there must be no single point of failure. Ultimately, the requirements can be used as a checklist to determine how successful the project was.
  • Really do list the requirements, even if it’s only in an email to a colleague saying, “This is what I think we need – have I missed anything?”. Once you’ve captured the requirements, run it past your IT people for their comments: they are likely to consider things you hve missed.
  • Consider whether cloud computing is the best way of meeting those requirements. Have a table with three columns, “Requirement”, “Cloud Computing”, “Traditional Hardware”, and go through the requirements, detailing how each approach would meet it together with any pros and cons.
  • If you do decide to use a cloud architecture, design it such that you can put a big red cross through any single item and explain a) how the service continues to operate without it and b) how the crossed-out item recovers.
  • Determine if and how your infrastructure will autoscale, and what parameters and values will cause it to a) autoscale up and b) autoscale down.
  • Ensure that you include a policy for backups and recovery. Consider whether you want the backups to be held by the same cloud vendor that has the original data.
  • Document how you will handle changes to the infrastructure over time. This will include building new images for instances and managing the rollout of those new images.
  • State what the data security requirements are and how each one will be met.
  • Detail what network connectivity will be required to the location(s) where your users are. What bandwidth will be needed? What resilience?

Conclusions

Cloud computing is undoubtedly of huge value when used correctly, but it is seldom, if ever, the only possible answer. As always, we should start with “What problem we are trying to solve?” rather than “How can I make this solution fit my problem?”. Perhaps unintentionally, the latter is a common approach but it often leads to a less-than-perfect result.

Could This Article Be Improved?

Let us know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *