How to define hybrid cloud service-level agreements

Public, private or hybrid cloud: end users don't care where their IT services are hosted -- unless a service goes down or data is lost -- then the pressure is on IT. As IT organizations adopt hybrid clouds, defining service-level agreements (SLAs) becomes increasingly difficult. However, it's not impossible. With a bit of foresight and understanding, IT can weave together a cloud service-level agreement that meets service levels as well as regulatory compliance, security and governance requirements.

"A hybrid cloud means a combination of services -- some public, some private -- and they work in unison as though they are a single system," said Judith Hurwitz, CEO and founder of competitive analysis firm Hurwitz & Associates. "The issue is that these are not static systems. Any one of the components could be the source of problems. Furthermore, your weakest link one day might not be your weakest link the next day. It's very fluid," Hurwitz said.

Therefore, it is essential that IT organizations understand who owns all the parts of the stack in the new hybrid environment. "As you introduce multiple players, you have to be very conscientious of who has what responsibility. When developing an SLA, you have to have a clear understanding of ownership and support at multiple levels of the stack," said Tim Burke, CEO of Quest, a Sacramento-based managed service provider.

For example, Burke said if you are using compute and storage from Amazon Web Services, then Amazon is managing those stacks and their security. "You think that's pretty well defined. You're just connecting to those things," he said. But by introducing the connectivity between private and public cloud, you've also introduced the transport issue, so you need to know who is responsible for that."

"The trick with any cloud provider is that there's a demarcation point between where the service provider's responsibility ends and where my responsibility starts. In a cloud service, [the demarcation point] is a layer in the application stack. Depending on the cloud service, it might be the OS, the platform as a service or a container. It can be one of any number of layers, but it always exists," said Abner Germanow, senior director of enterprise marketing for New Relic, a San Francisco-based software analytics company.

The trick with any cloud provider is that there's a demarcation point between where the service provider's responsibility ends and where my responsibility starts.

In addition to understanding this demarcation line, IT organizations need to understand the service levels a cloud provider delivers. "[Cloud services] provide an excellent platform based on the standards they've defined. If that works for you, that's great. But don't impart on them other attributes. It's not fair for them," Burke said. "Most public cloud providers focus on scaling, so sitting down and spend a lot of time with you to map out new service levels is outside their business model."

Hurwitz agreed. "Let's say you're a medium-sized company and you use Gmail as your email provider. You can't call up Google and say, 'This is what we demand of you for a service level.' You probably couldn't find anyone to talk to about that anyway." There is, perhaps, one exception: "If you're a multi-gazillion dollar company and you've signed up for a special service, maybe then you will have clout and they'll do something special for you. It's all a matter of scale and importance," Hurwitz said.

However, for the large majority of companies that are not multi-gazillion dollar companies, Hurwitz offered this advice: "You have to decide what tolerance you have for unpredictability. If the services fail in any way or slow down, it will impact revenue and your ability to do business. Think "What is the most secure, reliable deployment model that I can use for that service?'"

For example, if a company communicates with customers only via email then it is a mission-critical application. "You might have to pay a little more or look at a different strategy because you know if that service goes down for 10 seconds, you're hosed. It's not black and white. It's very much a balancing act," Hurwitz said. The organization must determine what areas are most critical, including performance and security requirements, and what backup strategy and DR strategies are in place.

"All of these become issues you have to figure out," she said, and then "you have to work on bringing elements together so that it gives you the service level that you require."

Germanow said there may be times when your service-level agreement with end users is more stringent than your cloud service-level agreement. "You might have an application architecture that fails over with multiple providers or otherwise triggers different availability scenarios so that the customer experience stays solid on your service-level agreement while the line you have with the various cloud providers might be much looser because you can fail over from service provider to service provider," he explained. "Understanding all that is pretty critical."