The Service Level Agreement
Purchasing goods and services online has become very easy, just a click here and there, input some credentials, and your bank account is now lighter. This is exactly the same with purchasing Cloud Computing services. It has become a bit worrisome if people actually know what they are getting into or are getting their money’s worth. Sure, you have certain expectations on the service based on what the service provider has advertised. But are you absolutely sure that you are getting what you want or need and are you interpreting those service descriptions accurately?
That is the reason why we have Service Level Agreements (SLA), they are a big part of the contract that you as a client goes into with your service provider. This lays out the specifics of what they are providing you and what penalties they incur in case they cannot live up to those agreements.
However, SLAs will differ dramatically depending on the nature of the cloud service and the company that wrote the SLA. There is no clear standard on what goes in a SLA and the things being specified there are all over the place. If you ask a SaaS provider they will give you one thing. Ask a PaaS or a IaaS provider and they will give you different answers. And it even becomes a lot more different for Private Clouds. Let’s try to categorize the different SLAs in terms of context.
- Managed Hosting Provider context. These providers, like traditional data center providers before them center their SLAs on the availability of their service. They use the familiar percentage availability notation. So if you want 90% (one nine) availability per year you have to pay a certain amount. If you want more, the price suddenly goes up. The percentage goes up to 99.99999% (seven nines) or only a total of 3.15 seconds of downtime per year. But the cost exponentially increases the more nines you want and the provider does not always deliver on this promise. When they can’t, the penalty is usually in the form of service credits. So the crappier the service gets, the reward is even more of it.
- Software Vendor context. When buying or renting software you do not get a SLA, but rather an End-User License Agreement (EULA) which spells out what you and the vendor can and cannot do with the software. When these vendors go Cloud as SaaS or PaaS providers, they usually retain much of that EULA which was vague and was plagued with restrictions to begin with. SaaS is really about software rather than services.
- Enterprise Operations context. In this case, there is an operations team assigned to each client to give the services they paid for. So depending on the IT needs of the company or the department, the OpsTeam will handle it. For example, a web site with specific requirements like less than 5 seconds response time needs to be set up, the solution architects will recommend hardware and related technology to meet the requirements, business department takes care of the bill, and the OpsTeam will keep everything running as per the requirements. The SLAs in this case will vary wildly depending on the role and requirements being set for the OpsTeam.
By Salam Abdul
He has recently co-authored: Deploying and Managing a Cloud Infrastructure: Real-World Skills for the CompTIA Cloud+ Certification (Wiley).