SLAs on public cloud
I am surprised why many people are somewhat shocked when faced with how to handle SLAs when talking about cloud computing. There have been many articles written about how you should negotiate SLAs with cloud providers. I think these articles are naïve, at best. They don’t understand cloud and they treat this as remote hosting or as a collocation vendor. I am hoping this will shed a little light on this matter so you can benefit from Cloud in the proper way. It is simply a matter of confusion with terminology and since we all love to use the same word in many contexts in the English language, I understand why this happens.
I think it all started with Amazon Web Services. I am talking about the confusion and how it started with the word “services”. In simple economic and business sense, a “service” is an intangible economic good. Like a barber cutting your hair or a plumber fixing your leak in your faucet. When businesses buy services from “service providers”, they usually do so based on a legal instrument for some price and at some performance; these contracts are commonly known as service level agreements or SLA. To ensure said performance, it is natural to get into “service level guarantees” and negotiate on service penalties, credits and so forth.
Now let’s talk a little computer science. A service is really a “computer program” that runs somewhere and handles a set of specific tasks. Like a UNIX sendmail or an sshd deamon or an application service on Mac OS or a Host Process which is a Microsoft Windows service; each one handles a specific task. All of these run within a context and a bunch of these together with other COTS and/or custom applications, take care of a business process.
Customers’, who signed up for “cloud” from AWS, were expecting a service, because it is in the name. Well they knew they were getting hardware on demand but most people said it is on the cloud and since you can’t touch it (the intangible part), it has to be a “service” that requires a contract. I don’t think this is what the cloud providers intended. Granted, some of the above mentioned cloud providers now are offering some sort of SLA to keep the peace but this is not going to help the majority of you with your SLA unless you take care of your business.
When you buy hardware for deploying assets on-premise or in your collocation site, your hardware vendor will not sign up for any SLA for your business application. Why then should a cloud IaaS provider do? If you have read this far, I really hope you are having one of those “Aha!” moments right now because this is the crux of your problem. Besides the pay per use, you can get your infrastructure already setup and available at the click of a button instead of the whole “buying and setting up the hardware process”. If something breaks on the cloud, you can get the same new thing quickly and you stop paying for the broken one. That’s what a public cloud promises and delivers. Now what about SLA?
There is just a simple matter that remains; you have to architect your business application properly for the SLA that you need. Just as you do in an on-premise situation, you have to do the same for the cloud as well. If you thought for a second that you don’t need a proper technical architecture simply because you are moving to cloud, you will be wrong and you will not have your SLA and this blame cycle starts over.
Architecting for the cloud means you make use of the benefits of the cloud just like you would extract all benefits from a new hardware platform you would buy. Isn’t it? So, architect properly or call us; we can help get your IT done properly, even on the cloud.