Service level agreements in Cloud Computing

A Service Level Agreement (SLA) is the bond for the performance of the negotiation between a cloud service provider and a client. Earlier, in cloud computing, all service level agreements were negotiated between a customer and a service consumer. With the introduction of large utilities such as cloud computing providers, most service level agreements are standardized until a customer becomes a large consumer of cloud services. Service level agreements are also defined at different levels, which are mentioned below:

• Customer-based SLA
• Service-based SLA
• Multilevel SLA

Some service level agreements are enforceable as contracts, but most are agreements or contracts that are more in line with an operating level agreement (OLA) and may not be constrained by law. It's okay to have a lawyer review documents before making any major settlement with a cloud service provider. Service level agreements usually specify certain parameters, which are mentioned below:

• Availability of the Service (uptime)
• Latency or the response time
• Service components reliability
• Each party accountability
• Warranties

If a cloud service provider fails to meet the specified targets of the minimum, the provider will have to pay a penalty to the cloud service consumer as per the agreement. So, service level agreements are like insurance policies in which the corporation has to pay as per the agreement if an accident occurs.

Microsoft publishes service level agreements associated with Windows Azure platform components, demonstrating industry practice for cloud service vendors. Each component has its own service level contracts. The two major Service Level Agreements (SLAs) are described below:

Windows Azure SLA -

Windows Azure has separate SLAs for computing and storage. For Compute, it is guaranteed that when a client deploys two or more role instances to different fault and upgrade domains, the client's Internet-facing roles will have external connectivity at least 99.95% of the time. In addition, all role instances of the client are monitored, and 99.9% of the time it is guaranteed to detect when the role instance's process does not run and starts properly.

SQL Azure SLA -

The SQL Azure client will have connectivity between the database of SQL Azure and the Internet Gateway. SQL Azure will handle a "monthly availability" of 99.9% within a month. The monthly availability ratio for a particular tenant database is the ratio of the time the database was available to customers to the total time in a month.

Time is measured in intervals of a few minutes in a 30-day monthly cycle. If SQL Azure Gateway rejects attempts to connect to the customer's database, part of the time is unavailable. Availability is always remunerated for a full month.

Service level agreements are based on the usage model. Often, cloud providers charge their pay-per-use resources at a premium and enforce standard service level contracts for just that purpose. Customers can also subscribe to different tiers that guarantee access to a specific amount of purchased resources.

Service level agreements (SLAs) associated with subscriptions often offer different terms and conditions. If the client requires access to a particular level of resources, the client needs to subscribe to a service. A usage model may not provide that level of access under peak load condition

Cloud infrastructure can span geographies, networks, and systems that are both physical and virtual. While the exact metrics of cloud SLAs can vary by service provider, the areas covered are the same:

• Volume and quality of work (including precision and accuracy);
• Speed;
• Responsiveness; and
• Efficiency.

The purpose of the SLA document is to establish a mutual understanding of the services, priority areas, responsibilities, guarantees and warranties. It clearly outlines metrics and responsibilities between the parties involved in cloud configuration, such as the specific amount of response time to report or address system failures.

The importance of a cloud SLA

Service-level agreements are fundamental as more organizations rely on external providers for critical systems, applications and data. Cloud SLAs ensure that cloud providers meet certain enterprise-level requirements and provide customers with a clearly defined set of deliverables. It also describes financial penalties, such as credit for service time, if the provider fails to meet guaranteed conditions.

The role of a cloud SLA is essentially the same as that of any contract -- it's a blueprint that governs the relationship between a customer and a provider. These agreed terms form a reliable foundation upon which the Customer commits to use the cloud providers' services. They also reflect the provider's commitments to quality of service (QoS) and the underlying infrastructure.

What to look for in a cloud SLA

The cloud SLA should outline each party's responsibilities, acceptable performance parameters, a description of the applications and services covered under the agreement, procedures for monitoring service levels, and a program for remediation of outages. SLAs typically use technical definitions to measure service levels, such as mean time between failures (MTBF) or average time to repair (MTTR), which specify targets or minimum values for service-level performance. does.

The defined level of services must be specific and measurable so that they can be benchmarked and, if stipulated by contract, trigger rewards or penalties accordingly.

Depending on the cloud model you choose, you can control much of the management of IT assets and services or let cloud providers manage it for you.

A typical compute and cloud SLA expresses the exact levels of service and recourse or compensation that the User is entitled to in case the Provider fails to provide the Service. Another important area is service availability, which specifies the maximum time a read request can take, how many retries are allowed, and other factors.

The cloud SLA should also define compensation for users if the specifications are not met. A cloud service provider typically offers a tiered service credit plan that gives credit to users based on the discrepancy between the SLA specifications and the actual service tiers.

Selecting and monitoring cloud SLA metrics

Most cloud providers publicly provide details of the service levels that users can expect, and these are likely to be the same for all users. However, an enterprise choosing a cloud service may be able to negotiate a more customized deal. For example, a cloud SLA for a cloud storage service may include unique specifications for retention policies, the number of copies to maintain, and storage space.

Cloud service-level agreements can be more detailed to cover governance, security specifications, compliance, and performance and uptime statistics. They should address security and encryption practices for data security and data privacy, disaster recovery expectations, data location, and data access and portability.

Verifying cloud service levels

Customers can monitor service metrics such as uptime, performance, security, etc. through the cloud provider's native tooling or portal. Another option is to use third-party tools to track the performance baseline of cloud services, including how resources are allocated (for example, memory in a virtual machine or VM) and security.

Cloud SLA must use clear language to define the terms. Such language controls, for example, the inaccessibility of the service and who is responsible - slow or intermittent loading can be attributed to latency in the public Internet, which is beyond the control of the cloud provider. Providers usually specify and waive any downtime due to scheduled maintenance periods, which are usually, but not always, regularly scheduled and re-occurring.

Negotiating a cloud SLA

Most common cloud services are simple and universal, with some variations, such as infrastructure (IaaS) options. Be prepared to negotiate for any customized services or applications delivered through the cloud. There may be more room to negotiate terms in specific custom areas such as data retention criteria or pricing and compensation/fines. Negotiation power generally varies with the size of the client, but there may be room for more favorable terms.

When entering into any cloud SLA negotiation, it is important to protect the business by making the uptime clear. A good SLA protects both the customer and the supplier from missed expectations. For example, 99.9% uptime ("three nines") is a common bet that translates to nine hours of outages per year; 99.9999% ("five nine") means an annual downtime of approximately five minutes. Some mission-critical data may require high levels of availability, such as fractions of a second of annual downtime. Consider several areas or areas to help reduce the impact of major outages.

Keep in mind that some areas of Cloud SLA negotiations have unnecessary insurance. Certain use cases require the highest uptime guarantee, require additional engineering work and cost and may be better served with private on-premises infrastructure.

Pay attention to where the data resides with a given cloud provider. Many compliance regulations such as HIPAA (Health Insurance Portability and Accountability Act) require data to be held in specific areas, along with certain privacy guidelines. The cloud customer owns and is responsible for this data, so make sure these requirements are built into the SLA and validated by auditing and reporting.

Finally, a cloud SLA should include an exit strategy that outlines the provider's expectations to ensure a smooth transition.

Scaling a cloud SLA

Most SLAs are negotiated to meet the current needs of the customer, but many businesses change dramatically in size over time. A solid cloud service-level agreement outlines the gaps where the contract is reviewed and potentially adjusted to meet the changing needs of the organization.

Some vendors build in notification workflows that are triggered when a cloud service-level agreement is close to breach in order to initiate new negotiations based on changes in scale. This uptime can cover usage exceeding the availability level or norm and can warrant an upgrade to a new service level.