Skip to main content

SRE Revisited: SLO in the Age of Microservices

Dotan Horovits
Logz.io

Site Reliability Engineering (SRE) practice was established by Google nearly 20 years ago and was popularized with Google's monumental SRE Book. Everyone's been attempting to follow that iconic path ever since.

What Are SLI, SLO and SLA Anyway?

SRE practice revolves around the concepts of SLO, SLI, SLA, and the related "error budget." The Google SRE Book, which laid the foundations for the practice, defines them as follows:

Service Level Indicator (SLI) is a carefully defined quantitative measure of some aspect of the level of service that is provided. Common examples include latency, error rate, request throughput and availability.

Service Level Objective (SLO) is a target value or range of values for a service level that is measured by an SLI. For example, an SLO can state that the average latency per request should be under 120 milliseconds. Many companies set SLO targets as a number of nines, for example "five nines" uptime means 99.999% uptime, which means a maximum of 5.26 minutes downtime per year.

Service Level Agreement (SLA) is an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. Put simply, if you've got a penalty attached to breaching an SLO — you're talking SLA.

SRE typically doesn't deal with SLA directly, as it's more commercial in nature. Rather, the SRE is concerned with meeting the SLOs that underlie the SLA.

Error budget is an important related concept, which determines the rate at which the SLOs can be missed. Error budget is an important indicator for meeting the SLO goals consistently, and SRE teams track it weekly and even daily. Error budget is also important, as it enables downtime windows that can be used for maintenance, experimenting with new features, and other innovation.

So How Is SRE Changing in the Age of Microservices?

The SRE concepts remain valid these days as they've been before. But then again, their system of reference has drastically changed.

SLOs have traditionally referred to assets such as the application's binary or other deployment artifacts. That made perfect sense when the binary encapsulated the entire application, or a major piece of it such as the business logic tier.

In the world of microservices, however, the deployed artifacts are, well — microservices. And as the name suggests, each individual micro-service executes only a tiny piece of functionality.
In such systems it makes little sense to track SLO on the individual artifacts. SLO should refer to the functionality that is meaningful to the users.

Therefore, the practice of monitoring SLO on the service binary is no longer relevant.

In microservice architecture, rather than the individual service, it is the mesh of services that needs to play well together to execute. In these systems, tens and even hundreds of services may be traversed in order to satisfy a single user request. In these systems, rather than monitoring individual services, SLI and SLO should be defined for flows and user journeys.

The complex request flows brought about the rise of Distributed Tracing discipline. It enables tracing a single request through the call chain between the different interacting microservices, by propagating context along the request path. It's typically used to pinpoint where failures occur and what causes poor performance. However, tracing can also be used to trace FinOps and business workflows.

Google Dapper is in fact one of the forefathers of modern distributed tracing, which served as inspiration for tools such as Jaeger and Zipkin. According to Ramón Medrano Llamas, a staff site reliability engineer at Google who leads the SRE team in charge of Google's identity services, "it's the closest tool we have right now for a definite observability tool."

To make things more interesting, these user journeys not only span several services, but may actually involve a few requests. Let's look for an example at the Google sign-in process: as Ramón from Google shares, what used to be a matter of three calls in the pre-microservices era, is today a full business flow, consisting of multiple steps: loading page, then putting username & password, then second factor auth. and so on. Each individual step is a request, triggering a chain of microservices to satisfy. And the overall multi-step flow isn't stateful, it depends on the end user to carry it over from step to step. Monitoring these business flows is less trivial, but that's what we need to measure to ensure the functionality we deliver to the user.

How should you go about defining SLO then?

■ Start by identifying the main flows and user journeys in your system. These should be well defined as part of the system and product specifications.

■ Then for each flow, clarify the expected end result from the user perspective, to define the SLI. This should also be a direct derivative of the product flow definition.

■ If needed, add missing instrumentation to track, collect and aggregate the relevant metrics to measure the defined SLI.

■ Make sure that the relevant flow context is propagated throughout your system. This will serve to associate a metric with the respective tenant, account or similar entities.

■ Carefully define the SLO around each SLI, to meet technical and business goals. This often involves additional stakeholders, to factor in the tradeoff between stability and velocity of innovation.

■ Start monitoring the SLI and set relevant alerting according to the threshold defined by the SLO. Track your error budget regularly to see how close you get to the SLO bar.

Dotan Horovits is Principal Developer Advocate at Logz.io

Hot Topics

The Latest

Businesses that face downtime or outages risk financial and reputational damage, as well as reducing partner, shareholder, and customer trust. One of the major challenges that enterprises face is implementing a robust business continuity plan. What's the solution? The answer may lie in disaster recovery tactics such as truly immutable storage and regular disaster recovery testing ...

IT spending is expected to jump nearly 10% in 2025, and organizations are now facing pressure to manage costs without slowing down critical functions like observability. To meet the challenge, leaders are turning to smarter, more cost effective business strategies. Enter stage right: OpenTelemetry, the missing piece of the puzzle that is no longer just an option but rather a strategic advantage ...

Amidst the threat of cyberhacks and data breaches, companies install several security measures to keep their business safely afloat. These measures aim to protect businesses, employees, and crucial data. Yet, employees perceive them as burdensome. Frustrated with complex logins, slow access, and constant security checks, workers decide to completely bypass all security set-ups ...

Image
Cloudbrink's Personal SASE services provide last-mile acceleration and reduction in latency

In MEAN TIME TO INSIGHT Episode 13, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses hybrid multi-cloud networking strategy ... 

In high-traffic environments, the sheer volume and unpredictable nature of network incidents can quickly overwhelm even the most skilled teams, hindering their ability to react swiftly and effectively, potentially impacting service availability and overall business performance. This is where closed-loop remediation comes into the picture: an IT management concept designed to address the escalating complexity of modern networks ...

In 2025, enterprise workflows are undergoing a seismic shift. Propelled by breakthroughs in generative AI (GenAI), large language models (LLMs), and natural language processing (NLP), a new paradigm is emerging — agentic AI. This technology is not just automating tasks; it's reimagining how organizations make decisions, engage customers, and operate at scale ...

In the early days of the cloud revolution, business leaders perceived cloud services as a means of sidelining IT organizations. IT was too slow, too expensive, or incapable of supporting new technologies. With a team of developers, line of business managers could deploy new applications and services in the cloud. IT has been fighting to retake control ever since. Today, IT is back in the driver's seat, according to new research by Enterprise Management Associates (EMA) ...

In today's fast-paced and increasingly complex network environments, Network Operations Centers (NOCs) are the backbone of ensuring continuous uptime, smooth service delivery, and rapid issue resolution. However, the challenges faced by NOC teams are only growing. In a recent study, 78% state network complexity has grown significantly over the last few years while 84% regularly learn about network issues from users. It is imperative we adopt a new approach to managing today's network experiences ...

Image
Broadcom

From growing reliance on FinOps teams to the increasing attention on artificial intelligence (AI), and software licensing, the Flexera 2025 State of the Cloud Report digs into how organizations are improving cloud spend efficiency, while tackling the complexities of emerging technologies ...

Today, organizations are generating and processing more data than ever before. From training AI models to running complex analytics, massive datasets have become the backbone of innovation. However, as businesses embrace the cloud for its scalability and flexibility, a new challenge arises: managing the soaring costs of storing and processing this data ...

SRE Revisited: SLO in the Age of Microservices

Dotan Horovits
Logz.io

Site Reliability Engineering (SRE) practice was established by Google nearly 20 years ago and was popularized with Google's monumental SRE Book. Everyone's been attempting to follow that iconic path ever since.

What Are SLI, SLO and SLA Anyway?

SRE practice revolves around the concepts of SLO, SLI, SLA, and the related "error budget." The Google SRE Book, which laid the foundations for the practice, defines them as follows:

Service Level Indicator (SLI) is a carefully defined quantitative measure of some aspect of the level of service that is provided. Common examples include latency, error rate, request throughput and availability.

Service Level Objective (SLO) is a target value or range of values for a service level that is measured by an SLI. For example, an SLO can state that the average latency per request should be under 120 milliseconds. Many companies set SLO targets as a number of nines, for example "five nines" uptime means 99.999% uptime, which means a maximum of 5.26 minutes downtime per year.

Service Level Agreement (SLA) is an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. Put simply, if you've got a penalty attached to breaching an SLO — you're talking SLA.

SRE typically doesn't deal with SLA directly, as it's more commercial in nature. Rather, the SRE is concerned with meeting the SLOs that underlie the SLA.

Error budget is an important related concept, which determines the rate at which the SLOs can be missed. Error budget is an important indicator for meeting the SLO goals consistently, and SRE teams track it weekly and even daily. Error budget is also important, as it enables downtime windows that can be used for maintenance, experimenting with new features, and other innovation.

So How Is SRE Changing in the Age of Microservices?

The SRE concepts remain valid these days as they've been before. But then again, their system of reference has drastically changed.

SLOs have traditionally referred to assets such as the application's binary or other deployment artifacts. That made perfect sense when the binary encapsulated the entire application, or a major piece of it such as the business logic tier.

In the world of microservices, however, the deployed artifacts are, well — microservices. And as the name suggests, each individual micro-service executes only a tiny piece of functionality.
In such systems it makes little sense to track SLO on the individual artifacts. SLO should refer to the functionality that is meaningful to the users.

Therefore, the practice of monitoring SLO on the service binary is no longer relevant.

In microservice architecture, rather than the individual service, it is the mesh of services that needs to play well together to execute. In these systems, tens and even hundreds of services may be traversed in order to satisfy a single user request. In these systems, rather than monitoring individual services, SLI and SLO should be defined for flows and user journeys.

The complex request flows brought about the rise of Distributed Tracing discipline. It enables tracing a single request through the call chain between the different interacting microservices, by propagating context along the request path. It's typically used to pinpoint where failures occur and what causes poor performance. However, tracing can also be used to trace FinOps and business workflows.

Google Dapper is in fact one of the forefathers of modern distributed tracing, which served as inspiration for tools such as Jaeger and Zipkin. According to Ramón Medrano Llamas, a staff site reliability engineer at Google who leads the SRE team in charge of Google's identity services, "it's the closest tool we have right now for a definite observability tool."

To make things more interesting, these user journeys not only span several services, but may actually involve a few requests. Let's look for an example at the Google sign-in process: as Ramón from Google shares, what used to be a matter of three calls in the pre-microservices era, is today a full business flow, consisting of multiple steps: loading page, then putting username & password, then second factor auth. and so on. Each individual step is a request, triggering a chain of microservices to satisfy. And the overall multi-step flow isn't stateful, it depends on the end user to carry it over from step to step. Monitoring these business flows is less trivial, but that's what we need to measure to ensure the functionality we deliver to the user.

How should you go about defining SLO then?

■ Start by identifying the main flows and user journeys in your system. These should be well defined as part of the system and product specifications.

■ Then for each flow, clarify the expected end result from the user perspective, to define the SLI. This should also be a direct derivative of the product flow definition.

■ If needed, add missing instrumentation to track, collect and aggregate the relevant metrics to measure the defined SLI.

■ Make sure that the relevant flow context is propagated throughout your system. This will serve to associate a metric with the respective tenant, account or similar entities.

■ Carefully define the SLO around each SLI, to meet technical and business goals. This often involves additional stakeholders, to factor in the tradeoff between stability and velocity of innovation.

■ Start monitoring the SLI and set relevant alerting according to the threshold defined by the SLO. Track your error budget regularly to see how close you get to the SLO bar.

Dotan Horovits is Principal Developer Advocate at Logz.io

Hot Topics

The Latest

Businesses that face downtime or outages risk financial and reputational damage, as well as reducing partner, shareholder, and customer trust. One of the major challenges that enterprises face is implementing a robust business continuity plan. What's the solution? The answer may lie in disaster recovery tactics such as truly immutable storage and regular disaster recovery testing ...

IT spending is expected to jump nearly 10% in 2025, and organizations are now facing pressure to manage costs without slowing down critical functions like observability. To meet the challenge, leaders are turning to smarter, more cost effective business strategies. Enter stage right: OpenTelemetry, the missing piece of the puzzle that is no longer just an option but rather a strategic advantage ...

Amidst the threat of cyberhacks and data breaches, companies install several security measures to keep their business safely afloat. These measures aim to protect businesses, employees, and crucial data. Yet, employees perceive them as burdensome. Frustrated with complex logins, slow access, and constant security checks, workers decide to completely bypass all security set-ups ...

Image
Cloudbrink's Personal SASE services provide last-mile acceleration and reduction in latency

In MEAN TIME TO INSIGHT Episode 13, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses hybrid multi-cloud networking strategy ... 

In high-traffic environments, the sheer volume and unpredictable nature of network incidents can quickly overwhelm even the most skilled teams, hindering their ability to react swiftly and effectively, potentially impacting service availability and overall business performance. This is where closed-loop remediation comes into the picture: an IT management concept designed to address the escalating complexity of modern networks ...

In 2025, enterprise workflows are undergoing a seismic shift. Propelled by breakthroughs in generative AI (GenAI), large language models (LLMs), and natural language processing (NLP), a new paradigm is emerging — agentic AI. This technology is not just automating tasks; it's reimagining how organizations make decisions, engage customers, and operate at scale ...

In the early days of the cloud revolution, business leaders perceived cloud services as a means of sidelining IT organizations. IT was too slow, too expensive, or incapable of supporting new technologies. With a team of developers, line of business managers could deploy new applications and services in the cloud. IT has been fighting to retake control ever since. Today, IT is back in the driver's seat, according to new research by Enterprise Management Associates (EMA) ...

In today's fast-paced and increasingly complex network environments, Network Operations Centers (NOCs) are the backbone of ensuring continuous uptime, smooth service delivery, and rapid issue resolution. However, the challenges faced by NOC teams are only growing. In a recent study, 78% state network complexity has grown significantly over the last few years while 84% regularly learn about network issues from users. It is imperative we adopt a new approach to managing today's network experiences ...

Image
Broadcom

From growing reliance on FinOps teams to the increasing attention on artificial intelligence (AI), and software licensing, the Flexera 2025 State of the Cloud Report digs into how organizations are improving cloud spend efficiency, while tackling the complexities of emerging technologies ...

Today, organizations are generating and processing more data than ever before. From training AI models to running complex analytics, massive datasets have become the backbone of innovation. However, as businesses embrace the cloud for its scalability and flexibility, a new challenge arises: managing the soaring costs of storing and processing this data ...