Grounded in the Cloud
Showing results for 
Search instead for 
Did you mean: 

Cloud Brokering: How to ensure your cloud provider can meet your SLA requirements




One of your public cloud services just failed, your users lost data, and your service provider has informed you that the failure and permanent data loss was within the bounds of their contractual commitments. You’re thinking “How can this be!! I thought the service met my requirements!” You paid for a service, and now they don’t deliver what you believe you paid for. This is just one example of what happens every day in the real world of cloud computing.

HPE Helion Cloud Broker Series.jpgWhen acting as a cloud broker, there are lots of choices to make among the public cloud providers. And while a service may look good on paper, how do you know if your requirements are actually being met? The worst way to find out the service isn’t meeting your needs is when the service fails. Typically, users don’t find out that a service doesn’t meet their requirements until after an issue occurs. An upfront and regular ongoing contractual audit, with use case stress tests, should be a part of your cloud brokering management process for each public cloud service in your service catalog.

The best way to review (or even select) each cloud provider is to first document your critical use case requirements for each service. As an example, if you need a service for software development, you probably don’t care about high availability or failover capability. If you’re putting confidential information on a public cloud service, you’ll want to insure the confidentiality and security terms and conditions, along with an appropriate level of contractual limits of liability, are appropriate. For each cloud service, you should have a list of criteria organized by critical, important, and nice to have.

A written validated contractual commitment should stand behind each “answer” (ie: “Can you show me where it says that in the service agreement and SLA’s”). All you need to know about your service should be in your service contract. If it’s not, assume you won’t get it. Here’s a list of items to consider:

- A detailed Service Level Agreement: You want to make certain the SLA meets your uptime requirements for the use cases it was contracted for. If the use case demands high uptime, you must understand the cloud services ability to fail-over. If the use case requires the data to be recovered from the cloud provider’s backup/recovery strategy, you need to know the commitment and timing to restore and ensure it meets the use case requirements.
- Confidentiality and Security: Make sure you know exactly who has access to your data. Even though it’s assumed the general public can’t access your cloud service, it’s likely the cloud provider’s data center personnel have access to customer’s data or have the ability to compromise the system. You may also want to select use cases where the programs run on public cloud but the data remains, and is accessed, within your own private cloud.
- Data center locations: Government regulations may require personal data to be stored within country boundries. Some country’s laws allow for direct access to information, if the country’s government requests it. In that type of scenario, sensitive company data might be inadvertently released. If possible, keeping sensitive data in-house is always preferable.
- Backup and recovery: If needed for the use case, you may want a documented backup and recovery strategy. Its critical to know what the backup strategy is for the public cloud service, including any offsite storage processes. It’s also important to understand how your backups are archived from a security/confidentiality perspective.
- Termination of service: If you committed a particular use case to a public cloud service and the service “evaporates” through the provider going out of business or simply deciding to terminate services, you need to have a plan to move the data and applications to an alternative environment and a reasonable amount of time to move it.
- Application performance requirements: The services compute, network and storage components need to meet the required use case application performance requirements
- Access controls: If the use case requires specific levels of control over the various cloud service components (physical server, the virtual server, the hypervisor, networking, storage), the contract needs to clearly state that that level of control.
- Limits of liability: What happens if all of your data and programs are lost due to a service failure? You need to ensure that your compensation from the provider, if any, appropriately matches the loss.

Going line-by-line through service agreements is a grueling, boring task but it is absolutely critical to do so. Failure to read and understand each cloud service provider’s terms and conditions is only setting you up for a costly business “surprise.” If you haven’t done this yet, run to your nearest Starbucks, get a gallon of double expresso coffee and start reading each contracted service provider’s terms and conditions and compare them to your written critical/important criteria. In the end, you’ll be glad you did.

0 Kudos
About the Author


Ken Won is the Director of Cloud Solutions Marketing at HPE. He is responsible for marketing the HPE Helion brand and HPE cloud solutions. Before joining HPE, Ken spent over 20 years in the high tech. industry at companies such as Sun Microsystems, Silicon Graphics, AMD and Force10 Networks. Ken has a B.S. in Electrical and Computer Engineering from University of California, Santa Barbara and an M.B.A. from Santa Clara University.

Jan 30-31, 2018
Expert Days - 2018
Visit this forum and get the schedules for online HPE Expert Days where you can talk to HPE product experts, R&D and support team members and get answ...
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all