In software engineering, the acronym SLA (Service Level Agreement) is ubiquitous but often misunderstood.
This article aims to clarify what an SLA truly is and to differentiate it from similar terms like SLI and SLO, which are often confused with SLAs.
What is an SLI
To understand SLAs, we first need to understand SLIs.
According to Wikipedia, “a service level indicator (SLI) is a measure of the service level provided by a service provider to a customer”.
These are quantitive measures such as latency, request throughput, and error rates.
What is an SLO
Building on our understanding of SLIs, an SLO can be defined as a “target value or range of values for a service level that is measured by an SLI”.
If SLIs are the raw metrics, SLOs are the goals set for those metrics. Often, people mistakenly refer to SLOs as SLAs.
Defining SLOs is not easy, but a good approach is to think of what is important to your users. A common mistake is to choose metrics that are easy to measure but may not provide significant value. It’s crucial to set objectives that align with what users value most.
For example, an SLO could be ‘my e-commerce platform will have an uptime of 99.9% over each calendar month’.
What is an SLA
An SLA (Service Level Agreement) is “an agreement between a service provider and a customer”. While people often refer to SLAs when they mean SLOs, the key difference is that SLAs include consequences for not meeting the agreed-upon service levels, often financial penalties.
An SLA comprises one or more SLOs. Unlike an SLO, which is a target with no fixed consequences for non-compliance beyond potential reputational damage, an SLA binds the service provider to certain standards with clear repercussions for failure.
I hope you learned something about these acronyms from this short article. Stay tuned for more insights in my future articles.