Defining Service Level Agreements
A service level agreement (SLA) is a document that captures the understanding between a service user and a service provider that defines uptime, availability, and performance. The SLA is also the contractual agreement between the participants in a service delivery contract. In the world of computing, an SLA is typically written based on the expectation that a system could be operational 99.99 percent of the month. It may also specify that the service provider’s help desk will respond to an outage in a set amount of time. Also, there’s an expectation that the service provider will not share a company’s information with anyone and that data will be preserved for a set period of time and backed up on a regular basis.
SLAs inside the firewall
Typically, two types of SLAs are in a traditional on-premises computing environment:
An SLA between the business and IT
An SLA between the business and an outside services provider
In both situations, a contract specifies both expectations and penalties. Clearly, an SLA with an outside service provider is more explicit because it’s a legally binding contract.
Between the business and IT, the SLA takes on a different flavor. For example, members of the accounting department may need the assurance that they will have the highest level of service when accountants are finalizing their end-of-the-month reporting. On the other hand, in the middle of the month, a lower level of service is acceptable. The manager of the accounting department understands that he will pay a higher fee at the end of the month and a smaller amount in the middle of the month. When accounting is based on an on-premises model, the fee may be in the form of a charge back based on usage of IT resources. On the other hand, if that same accounting department is using a SaaS accounting service, the company may have to purchase a more robust service package from the vendor.
Other issues important to the accounting department include things such as a high level of security for financial data and a secure connection between the office and the suppliers that are paid via an online service.
The cloud SLA
In a hybrid cloud environment, the SLA becomes more complicated than in an SLA for a private cloud service, which is very similar if not identical to the SLA between a business unit and the IT organization. (After all, the private cloud is a service within the data center that is optimized for self-service provisioning for internal customers and business partners.) Each cloud public service provider — whether it is a provider of IaaS, SaaS, BPaaS, or PaaS — will provide SLAs to cover the types of guarantees they are willing to provide to customers. But the problem for a business that might use a combination of public and private cloud services would ideally like to have a single SLA for the hybrid environment.
The bottom line is that it is hard to manage individual cloud services as though it were a single cloud environment; in reality, a hybrid cloud is a combination of many different services from many different vendors. The consumer sees the IT organization as responsible for providing them the type of service they expect. Therefore, the IT organization has to manage the SLA provided by each public cloud vendor, the SLA it has for the services it provides, and rationalize the combination.
When a company uses public cloud services, there are different expectations for an acceptable service level between the consumer and the provider. The consumer of the services expects on-demand access to services like e-mail or customer relationship management that they depend on. The service provider, on the other hand, wants to limit its liability in case of a service interruption. For example, a developer might go to Amazon.com to experiment with developing an application. That developer uses a credit card to pay for the service and builds the prototype application. Because that application is an experiment, the developer may be less concerned if the service is down for an hour. In fact, the developer might not even think about the service level at all. However, if that same developer is building an important application using Amazon.com, the expectation of uptime performance will change.
However, this starts to change if your organization uses public cloud services in combination with private cloud services as part of an overall computing environment. In this case, there may be an expectation that the public cloud service provider follows the same rules as the internal IT organization. Yet, this is not always the case, unless the public cloud service is designed and marketed with a higher level of service.
To get an idea about what you’ll be dealing with, check out the SLA on Amazon.com’s website. In case you don’t feel like reading this fine print, it basically means that if the service doesn’t achieve 99.95 percent uptime and your service is down for more than five minutes, you’re eligible for a 10 percent credit. However, if the outage is related to your service provider, your software, your systems, weather, and so on, the outage is not Amazon’s responsibility.
Although you might be pleased to know that a public cloud service provider will give you some money back, the issue is actually more complicated than it might appear at first glance. Say that you spent $5,000 to buy some compute capability from a public cloud provider. There’s an outage that the company took responsibility for. You are sent a check for $50. But this money does not reflect the lost opportunities that may result from an outage. For example, imagine that during an outage, several important customers who were about to place significant orders were unable to execute their orders. One customer simply delayed the purchase until the following month. However, another customer actually went to a competitor. That sale was lost, which quite likely led to lost customer confidence. The bottom line is that an SLA has to take into account the impact of the service on the customer experience and revenue.
An SLA is a piece of paper, isn’t it?
As much as we would like to promise you that if you simply create a hybrid cloud SLA, life will be perfect — we can’t. The SLA is no better than the thinking and planning that goes on behind it. Although we think you need to think about an SLA for your hybrid environment, don’t get lulled into thinking that’s enough. Instead, you need to spend your time planning and coordinating.
The hybrid cloud offers a lot of flexibility that can be an economic and business benefit. However, the service level has to be understood from a holistic perspective. So, as a starting point, remember these three rules:
Read the fine print. Remember that your cloud providers’ agreements are there to protect them, not you.
Coordinate. Look at your cloud services as an overall computing environment. You need to understand which services work together and which ones are stand-alone. For example, the public cloud service that’s used to try to create new applications probably won’t be part of the coordinated plan. However, the three SaaS applications that are part of a single business process need to have a coordinated SLA.
Think cloud management. It’s easy to be lulled into thinking that service levels are the responsibility of the cloud vendors you’re working with. The truth is that the customer experience is still your responsibility.