SLAs and SLOs have a cool, uncomplicated, and non-judgmental friend—Service Level Indicators, or SLIs, for short. And today, I'm here to introduce you to them and explain why they just may be your new BFF. Before I get to that, though, there are a couple other things I need to address...
Wow, it’s been a long time since I’ve posted anything here! Sure, I’ve been involved behind the scenes and have participated in some webinars and videos, but that doesn’t really make up for my lack of representation here on the Isos Technology blog. Prior to this conspicuous gap, I wrote a ton of posts myself, all while driving my Isos colleagues to produce their own posts (with much fist shaking behind my back, I’m sure).
But enough lamenting my lack of output over the last year, because that’s not really why either of us is here.
Anyone who has spent any time around the technologically inclined knows how much we love our acronyms. If something can’t be expressed with an acronym, does it really exist? The draw of the acronym is the ability to condense a complex concept or long string of words into something that is easier to convey, digest, and remember. Without this mechanism, it would be nigh impossible (or, at the least, much more time consuming) to have conversations about technology.
Assigning an acronym to something reflects the human drive to gain power over a thing by naming it to rein in the ever-growing ocean of technology that surrounds us. To read a bit more about the power of naming, check out this article from The New Yorker, and please accepts my apologies for the hours you are going to waste going down the Google rabbit hole on that topic).
Now, getting back to those Service Level Indicators, or SLIs. They are a concept that you may have already heard about, but didn’t have a specific word or acronym for. An SLI is a measure of an aspect of a service that can be quantified, such as site availability, latency, or throughput. Think of SLIs as building blocks for more complex business drivers.
SLIs are merely quantifiable values—they don’t make judgments as to cause. A base measurement of latency doesn’t care about the reason for the latency, it just reports on what the latency is. Think of it like a bathroom scale. The scale doesn’t care why your weight is up or down (unless it’s an IoT device like the one that nags me, but that’s a whole other discussion), it just reports back what your weight is.
While SLIs don’t make any judgments, when you're defining them you need to consider the overall objectives of your services. There are an infinite number of things you can quantify in a system, but the majority of the measurements will not add value in the end. Here’s an open secret: engineers and system administrators have a tendency to overcomplicate solutions. Shocker, I know! When designing your SLIs, it is very important that you avoid this trap. While SLIs may have differing levels of complexity, you should drive for simplicity when possible. This will make your SLIs easier to implement, modify (yes, they will evolve over time), and consume further up the chain.
Speaking of further up the chain, what am I alluding to? On their own, SLIs have value, though their potential isn’t achieved in a vacuum. They work best when fed into Service Level Objectives (SLOs) and Service Level Agreements (SLAs). We’re only two vowels, and maybe a sneaky cousin, short of having a full set. While I’m not going to go into those in this post, rest assured that I will be diving into them in future posts.
I think I’m going to sign off for the day. In the meantime, here are a couple of things to consider until next time: