Working On A Cloud Software Service Level Agreement

Working On A Cloud Software Service Level Agreement

As more and more consumers outsource their infrastructure to cloud providers, Service Level Agreements between consumers and providers is a key topic. According to IBM a Service Level Agreementdefines how the consumer will use the services and how the provider will deliver them”.

It is essential for the consumer of cloud services to understand all the terms of the cloud’s provider and to consider the needs and objectives of his enterprise before signing an agreement.

A Service Level Agreement should contain the following aspects:

  • A list of the services the provider will deliver and a complete definition of each service.
  • Metrics to determine if the provider is delivering the service as promised and an auditing mechanism to monitor the service.
  • Responsibilities of the provider and the consumer and remedies available to both if the terms of the SLA are not met.
  • A description of how the SLA will change over time.

Before signing an agreement, the customer should thoroughly inform in regards to the types of SLA’s that exist: off-the-shelf, customized or negotiated agreements. Clients with critical data or applications are recommended to negotiate their agreements in order to meet their needs.

Customers and providers should collaborate when putting in place a cloud software Service Level Agreement so that the provider services would best fit the customer’s needs. As discussed in the article Most common problems with the adoption of SaaS and how to overcome them, problems occurred with cloud providers can be avoided with a solid Service Level Agreement. I also have some other recommendations before signing an agreement:

  • Read your cloud provider’s SLA very carefully
  • Get the technical staff involved in the process of validating SLAs against common outages scenarios
  • Have your own back-up plan to support worse case scenarios. Never leave this responsibility only for your provider.

Final tip, a Service Level Agreement should be beneficial for both the customer and the provider and the best solution for the business.

By Rick Blaisdell / RicksCloud

Follow Us!

cloudtweaks

Established in 2009, CloudTweaks.com is recognized as one of the leading authorities in cloud computing information. Most of the excellent CloudTweaks articles are provided by our own paid writers, with a small percentage provided by guest authors from around the globe, including CEOs, CIOs, Technology bloggers and Cloud enthusiasts. Our goal is to continue to build a growing community offering the best in-depth articles, interviews, event listings, whitepapers, infographics and much more...
Follow Us!

Comments

  1. MaxBuchler says

    One thing I would like to add; non claim based penalties. The CSP should without a claim from the customer either pay a penalty or give a discount when the service doesn’t meet the SLA. The customer shouldn’t need to claim it.

    • sarojkar says

      Companies can insist on SLAs that reflect the full scope of service. For example, if cloud provider serving up hardware infrastructure like routers, network, server, and application infrastructure then make these as part of the SLA selection process. It also makes sense to collect SLAs from other cloud providers so you can compare what others are offering.

      • MaxBuchler says

        @sarojkar Do you mean like a complete chain with several services included in a “full” ITaaS/XaaS? Or do you mean net, servers etc within the DC included in a SaaS? (Then it definitely should be included in the SLA) If ITaaS; it’s definitely cool to deliver the chain of services from DC to user. It’s a risk but definitely cool, you will certainly differ from many other SP’s. As long as you can control services and functions in the chain + secure important and sensitive functions with redundant or hq components + not to forget; deliver top notch stable IT services, I would take the chance – you differ on the market. The weak part, according to me, because it’s normally out of your control, is the carrier. A cloud service should normally be available from I-net and I wouldn’t guarantee the whole chain when I-net is a part of it (which you of course could disclaim in the terms & cond). To me the chain delivery model is more applicable in an ITO model than in cloud, maybe in a private cloud.

        I agree: you should compare.

        • sarojkar says

           @MaxBuchler  What I mean say is that these items need to be discussed and put in paper as part of SLA. You don’t want to be in a situation where your provider is pointing a finger at the infrastructure issue or outage and saying it wasn’t their fault. Incorporate SLA terms that indicate how your company will perform based on these resources. What does it mean to your operations if the cloud is down? When will you be using the service? How long can your business operate without the cloud service? What are your non-production times? What is your company business continuity plans in case of a cloud service outage? Latency might be a problem with cloud providers, so you need to consider that aspect too.

        • MaxBuchler says

          @sarojkar Yes, I certainly agree. There should be no such thing where CSP’s can get away blaming service outage because of the underlying functions/infrastructure (including bugs – choose another part from another vendor if buggy). It’s the CSP who choose which part’s building their service. If the CSP doesn’t choose great and reliable parts the customer shouldn’t suffer because of bad choices. Unfortunately these might be risks the CSP calculate, where the SLA and penalty becomes just some numbers. Hopefully not but it might be a risk for the customer. Since it’s more accepting T&C’s than negotiating contracts when it comes to cloud. Therefore, as you said earlier; compare/benchmark, check for references and read T&C’s carefully. Also; as a professional business you should always analyze risks, impacts etc. whether cloud, ITO or on-prem and don’t end up with your pants down – outages do happen.

  2. sarojkar says

    Companies can insist on SLAs that reflect the full scope of service. For example, if cloud provider serving up hardware infrastructure like routers, network, server, and application infrastructure then make these as part of the SLA selection process. It also makes sense to collect SLAs from other cloud providers so you can compare what others are offering.

  3. sarojkar says

     @MaxBuchler  What I mean say is that these items need to be discussed and put in paper as part of SLA. You don’t want to be in a situation where your provider is pointing a finger at the infrastructure issue or outage and saying it wasn’t their fault. Incorporate SLA terms that indicate how your company will perform based on these resources. What does it mean to your operations if the cloud is down? When will you be using the service? How long can your business operate without the cloud service? What are your non-production times? What is your company business continuity plans in case of a cloud service outage? Latency might be a problem with cloud providers, so you need to consider that aspect too.

Add Comment Here