Best practices for standardizing SLAs for cloud computing

In addition, cloud providers must evaluate their relationships and SLAs with suppliers, enterprise data centers, http://www.aliyun.com/zixun/aggregation/35930.html > Network providers and content providers. There are many considerations that need to be taken into account. In this article, the author explores best practices for standardized SLAs.

TM Forum defines an SLA as an expectation of quality of service, priority, and responsibility between two or more parties. Cloud Standards Customer Council The cloud SLA as a written expectation of services between cloud users and providers. It provides guidance to decision makers on how to evaluate cloud computer providers and what to expect and what to look for when comparing end user SLAs. Policymakers should also assess the SLAs that cloud computing providers have with suppliers, enterprise data centers, network providers, and content providers.

SLAs are not mandatory when SLAs are driven by significant reorganization, redundancy, service consolidation, or transition to a cloud service environment. It does not have input from all relevant parties involved.

SLAs are not a single direction solution. One side (for example, a cloud service provider) should not decide how things are done, especially when the other side (for example, cloud service users) has different opinions about how the SLA is made.

SLAs are not a quick solution. It is not possible to leave enough time for the parties to understand the expectations of other parties, especially when there is a different understanding of the meaning of a term, if the negotiation process of the terms and conditions in the SLA is to be urgently promoted.

The author's hands-on experience with SLA

A few years ago, DeveloperWorks published a series of my articles on SLA, a total of 7 parts. Later, the United States a major federal agency of the Web services and service-oriented architecture of the director contacted me. He likes me. This article uses SLAs in the context of WEB services, part 7th: Reducing the risk of vulnerabilities with SLA guarantees. This article talks about breaking thresholds that determine whether the enterprise can be rescued from outright service denial (DoS) and critical system assets, and how disruptive thresholds affect SLA guarantees.

In contacting the head of the agency, I mentioned another article in the series that guarantees Web services with SLAs. In this article, I talked about 6 test types that you can use to test Web service features before exposing services:

Statefulness: Did the server respond in the correct step? Access: Can an unauthorized user successfully access controls that only administrators have permission to use? Response time: Does the application take too long to respond? Time-out: What happens when the application times out? Versioning: Can a new build break the functionality of an existing application?

I also mentioned some exceptions that might be included in the SLA:

failures: Hardware, communications, software, and performance monitors. Network issues that are outside the direct control of the service provider. Service refusal: Negligence or intentional action by a customer; Force majeure; war, strike, communication is not available; the goods and equipment required for the SLA requirements are not available. Regular maintenance: hardware and software upgrades and backups.

The head of the agency invited me to give a speech and have a system engineering discussion with his team. In my speech, I set out all the above points and also introduced the importance of the exit clause within the SLA. This clause allows the user to exit from the SLA if the promised warranty is not met multiple times.

After commenting on the views of my presentation, the executive sent me a copy of his organization's SLA template for me to review and asked me to help develop the first and subsequent versions of this template. (For reasons of secrecy, I can't discuss the details here.) It eventually became part of the federal system.

This SLA template can be extended to all cloud-based services. Regardless of which type of service is provided: WEB services, cloud services, and network access services, all SLAs are about service assurance. If the service guarantee is not satisfied, the penalty should be imposed. The level of service guaranteed varies among partners.

Not all WEB services, such as a cloud based SOA application, are based on clouds. SOA is a design pattern that consists of loosely coupled, discovered, reusable, interoperable platform-independent services through WEB service standards. SaaS is a usage model that uses resources hosted by a cloud service provider. SOA is a design model in which there are no restrictions on who users are.