As with IT generally, there are a lot of facets to “cloud computing”. Some companies deliver cloud services for end-users (facebook or Microsoft’s hotmail for example). Some, like Workbooks, deliver services for other companies. And some companies deliver services to support other companies’ delivery of cloud services.
Amazon Web Services is perhaps the leading provider to such services – it is a division of Amazon which many organisations use to power their IT services by providing them with computer and storage capacity “on demand”. If you take Amazon’s Web Services’ main offering – EC2 – then you are renting “virtual machine instances”. These are systems on which you can run your own operating system and they share a portion of the underlying hardware’s resources. You are of course sharing hardware with other EC2 customers and it’s down to chance whether your fellow virtual machine users are resource hogs or not. So there are now cloud services which help you manage your Amazon Web Services and it’s perhaps unsurprising that some of them report variations in EC2’s performance.
This last category poses an interesting question if you believe in the power of the cloud computing model: if you are going to deliver cloud services yourself, should you rely on other cloud services to deliver some of your underlying components? Certainly a model where Workbooks was built upon cloud services from other providers would have its advantages: we’d only pay for exactly what we used, and it would be very easy and very fast to add capacity: simply order some more and turn it on, on demand.
When things go according to plan, everyone’s happy. But if things become unreliable it’s Workbooks which our customers would see failing – and those customers would be right to expect Workbooks to stand behind the service and remedy it. Excuses such as “it’s our supplier’s fault” just wouldn’t cut it. When you have very large third-parties delivering components of the service it’s unlikely that Workbooks’ top priority would be their top priority.
Basically, we think that the cloud model is something which works – brilliantly – where there’s a simple customer/supplier relationship but that it can break down when there are hierarchies of services unless you think very carefully about how you will deal with the contingencies. It’s a little different from traditional business relationships where you have the luxury of at least a little time to sort out most issues: we need our infrastructure to be always available and reliable. We don’t want to be involved in trying to diagnose a third-party infrastructure (like EC2) and having the responsibility to sort out issues within it without having the ability to do so.
So we took a different route. We built our own infrastructure and we are responsible for its management – right down to the hardware. Although we do use third parties for some of the components, there is always redundancy: multiple networks, multiple locations. If a provider fails to deliver a service we can call on an alternative so we can be certain we can deliver the service levels we commit to in our SLA. Maybe we will use some Amazon services in the future but if we do they’ll be non-core and we’ll be sure to have a backup plan.