As many businesses depend on the cloud, having an agreement in place makes sense. But what is a service level agreement (SLA)? This guide goes through it all.
So many businesses depend on the cloud. It’s vital to their everyday operations. As such, it makes sense to have an agreement in place with the cloud service provider.
Such an agreement is called an SLA. SLA stands for Service Level Agreement. SLAs are not only used in cloud computing - they can be in place where any external service is being provided. However, they are commonly used for SaaS, Iaas, or PaaS products. As such, the definition of what a service level agreement is shifts. It all depends on what service is being provided.
SLAs can differ from provider-to-provider, although there tends to be a standardised foundation. With any SLA, there are some fundamental points that should be covered.
We’ve put this guide together for those who are new to cloud services and want to understand cloud SLAs better. We’ll be covering what exactly an SLA is, their benefits and why it’s important to get to grips with them.
Here’s what we’ll be discussing:
What is a Service Level Agreement in Cloud Computing?
What Criteria Does a Cloud SLA Cover?
Why is a Service Level Agreement (SLA) Important?
What if Something Goes Wrong?
SLO vs. SLA: What’s the Difference?
An SLA in cloud computing is an agreement between the cloud provider and client. It sets expectations for both sides. It establishes who is responsible for what, and details what their responsibilities are. These cloud service agreements are usually set up by the cloud provider.
A cloud SLA pays specific attention to the services a cloud provider manages. It’ll also explain the procedures on how the services that the provider offers are monitored.
An SLA establishes what a cloud service can offer and also acts as a form of warranty. With any service, clients need to know what to expect as a standard rate of operation. Think of these as ground rules. These particularly come in handy in case anything goes wrong. If you don’t know what is going on, how will you understand what the problem is?
An SLA will also help clarify what is routine maintenance and what is an unexpected challenge.
Examples of service level agreements are different depending on the provider. However, there are some specific criteria that you should pay close attention to.
Availability and uptime relate to users being able to use their applications. But just because an application is up, doesn’t automatically mean that users can access it. This is the difference between availability and uptime - the train may arrive at the station (uptime) but travellers may be unable to enter due to a fault in the doors (availability). Both availability and uptime are critical to cloud service users. This is especially true since an application might be affected by the availability of underlying infrastructure: so the application might be up, but still not be available if there is an infrastructure issue so it cannot be served. Without availability and access, a digital application can’t be used.
The terms for availability and uptime will differ in SLA agreements. In the industry, these terms are sometimes conflated. They tend to be established time parameters, usually hours and/or monthly cycles. For example, you might see ‘expect 99.95% 24/7 uptime during a 30-day monthly cycle’. Access to applications and data must be available within these stipulated terms.
The SLA should include details of what the cloud provider will do if the infrastructure goes down. It should also state that scheduled maintenance procedures will occur, how users will be informed of these ahead of time, how much notice they'll get and how these instances could affect uptime or availability.
Performance relates to the accuracy, efficiency, speed and responsiveness of cloud services. It also includes the volume of tasks it is able to successfully undertake. This is another important criteria to be covered in an SLA.
Performance parameters will take into consideration peak times and average workloads. It’ll then establish a baseline of operations. This is a level of performance that users can expect to get from their cloud services.
As a third party’s services are being used, security protocols are paramount to include in an SLA. This is a very important clause to have. A lot of sensitive information could be vulnerable without adequate security procedures. These need to be set in place and be explained. Otherwise, users cannot guarantee that their data will remain safe.
The SLA will detail its security processes, as well as its privacy procedures. Within this section, there will be details on data handling, how it will be kept secure, as well as user access. This should include:
Ownership: who owns the data that is being used in the cloud services? This, ideally, should be the client.
Location: is where the data is being stored, and how it is being handled, in line with local legislation? Think GDPR.
Access: users should be able to gather all of the data stored in the cloud services.
Portability: users should be able to move all of their data to another cloud service provider if they wish.
An SLA should include what it is needed to run the cloud services, both hardware and software. This can help clients understand how the services actually work. It also details the equipment and resources needed.
Things can go wrong. No service can run at 100% all of the time – even an update requires a sliver of downtime. Business continuity plans for more significant issues mean that when services go down, failover plans will usually move things to another container or cloud service geographical region, if necessary. Full and rolling outages are unusual in today’s cloud world. However, in these instances, an SLA needs to detail what the cloud provider will do if something goes awry. Attention also needs to be paid to the storage and restoration of data. No one wants that to get lost!
This clause may include details of automatic backups and data snapshots, what to expect if there is a period of downtime, business continuity plans and any measures a user can take to help the recovery process.
An SLA is a two-way agreement. This section will list the client’s responsibilities. It will also include anything they are liable for. This includes keeping business details accurate and up-to-date with and providing information to assist with performance issues. This also includes any changes in business requirements. These may result in the SLA needing to be revised.
This section of the SLA should detail what support options are available to clients. It should also share what the processes are to identify and resolve problems. This can include information on who to contact, what response times to expect or what times are guaranteed, and so on.
With most digital services, updates and new offerings are part of the package. An SLA will detail how it will introduce and manage any changes in its services. It should then note how this may affect availability, uptime, and performance.
When certain things go wrong, sometimes a complaint needs to be raised. In this part of an SLA, the dispute process will be detailed. This will include what the escalation steps will be, any mediation procedures and the consequences of breaches of service.
Despite best intentions, sometimes things just don’t work out. This clause of the SLA goes through the exit process of removing the service. This part will go through what the provider will do to ensure that the exit is smooth. It'll also detail what they’ll do if the client is transitioning to a new service provider.
We may joke about not reading terms and conditions, but getting to grips with an SLA is really important. Especially for something as vital as the cloud. Your whole operation could go belly up, and you just won’t know what to do.
SLAs protect clients, their data, and they establish a standard quality of service (QOS). It’s a bit like insurance. The clauses in an SLA establish:
The minimum level of performance and the consequences if these aren’t met
The ownership and rights to your data
How the service and its infrastructure actually works
Your right to audit the provider’s security compliances
Your right to leave or terminate the service
Details of penalties. Think service credits if certain levels of service aren’t met.
If you’re unsure of anything detailed in an SLA, it’s worth getting a developer to look through it. Ask them whether it covers common performance and availability scenarios.
An SLA is beneficial for everyone involved, as it:
Provides support for both the user and provider
Sets expectations on both sides
Helps with benchmarking metrics
Helps clients understand how the provider’s services work
Conveys company specific uptime and/or response time requirements
SLAs can be seen to be in favour of the cloud provider. But remember, it’s in their interest to offer a standard quality of service (QOS).
Some clauses can sometimes include general statements without going into detail. It’s always worth interrogating these further with your provider. You want to know exactly what you’re agreeing to. You may also want to negotiate some terms if they’re not covered in the SLA. However, do note that the success of this may depend on the size of your organisation.
When going through an SLA, designate specific metrics for different clauses. This makes benchmarking the service quality a whole lot easier.
The majority of SLAs cover an organisation’s current needs. However, it’s good practice to review it as it stands and see if there’s room for scaling within the agreement. For instance, if you want to run more applications in the future, are these covered in your current SLA?
The client is responsible for informing the provider if their business needs change. An SLA can be changed for both the client or the provider. It should be regularly reassessed to ensure it’s hitting the mark for everyone involved. But remember, the service provider is in their rights to push back on any drastic changes.
Sometimes, services can run a little slow. But in some instances, you may experience something more drastic like a cloud outage. Something like this may seriously affect your operation. Problems, although not common, do happen. As such, it’s valuable to have a contingency plan in place for such eventualities.
As mentioned before, it’s well worth reading through your SLA. You want to understand exactly what it covers. Different services, different regions, and so on, may or may not be included. This is important, as it affects if you're entitled to compensation if something goes awry.
Before we wrap things up, let’s take a look at something that can cause a little bit of confusion.
A SLA is different to an SLO. SLO stands for Service Level Objectives. These are performance metrics agreed to by the client and service provider. An SLA states what level of service to expect. An SLO goes deeper and defines this goal further with something that can be measured.
SLOs can be used in an SLA as an additional layer. Sometimes they’re specific to a particular organisation. These will have been negotiated with a service provider. Do note that not all SLAs will include SLOs.
In short, SLAs are a type of insurance document. As the customer, you want to know you’re getting what you’re paying for. It is worth interrogating SLAs and gaining a full understanding of them. You want to know exactly what to expect, how it works, and what will happen if things stop going to plan.