Tag: cloud service provider

I have mentioned in previous posts that when it comes to moving systems into the cloud, one of the key areas to ensure is covered is that of the contract. As you move systems to the cloud type model, you as a business or IT department become more and more abstracted from the underlying architecture and rely on the CSP (Cloud Service Provider) to have the architecture covered.

While in many ways this is great as the CSP will have considerably better infrastructure and a larger IT department than you as the customer so not only do you need to worry less about the services that support your systems, they are likely better set up and managed than if you tried to do so in house.

However the downside of this is that you are very much more beholden to contracts and service level agreements. As such ensuring the you completely understand the terms of the contract you sign with the CSP, including SLAs, where your data is, how it is handled, what levels of performance, scale, DR etc. you are entitled to is critical.

To help with this CloudPro have recently published a couple of articles on what should be in the contract (part 1) and what to look out for in the fine print (part 2).

is undoubtedly true and factually correct, in that recent storms caused issues with Amazon’s data centre in Ohio, and previously they have had issues when their data centre in Ireland was damaged by lightening, the question should be what could be done differently, rather than ‘cloud services are not robust / safe.

I am a firm advocate for insuring you understand your contract with your cloud provider with and that you pay great attention to things like SLAs and guaranteed uptime. This is especially true if you are using SaaS or PaaS type services that may in turn rely on another vendors IaaS service – you need to understand the layers to ensure your provider is not offering SLAs that it cannot meet due to them being more stringent than those of the providers of the services on which it relies.

However I question why this is considered an issue particular to ‘cloud’ based services. These same issues could happen to any co-location / data centre hosting solution, and these along with many more minor issues are likely to cause disruption to anything you host locally in your server room no matter how grand a name you give it. Sorry that’s one of my other pet hates, businesses with small server rooms that insist on calling them ‘data centres’ or other grandiose names and talking about them as if they are a large and resilient as actual Data Centres etc.

Anyway, back on topic, obviously when a cloud service provider has an issue it is likely to affect many customers so will be news worth, but before you worry too much or begin to dismiss the idea of moving some or all of your service to the cloud, ask yourself is it likely to be more or less robust than hosting things yourself?

Take the necessary precautions;

-Understand the offering you are purchasing, the SLAs and guaranteed uptime in the contract,

-Build BC and DR into your service; ensure it is replicated to multiple servers and disks locally, and to another geographically disparate data centres and you can host a hugely robust solution in the cloud.