Nobl9 this week added an ability to combine multiple service level objectives (SLOs) into one logical entity that DevOps teams can combine to more easily track specific user journeys and processes.
Brian Singer, chief product officer for Nobl9, said the latest update of a Nobl9 Composite SLO feature will make it simpler to collaboratively monitor an SLO, made up of SLOs that were originally created by different members of a DevOps team.
That capability also makes it simpler to observe the behavior of complex systems to better understand which errors are the root cause of an issue without necessarily having to analyze a massive amount of data, Singer added.
DevOps teams can also assign weights to specific SLOs, to ensure that services that have a larger impact on user experience help prioritize any error remediation efforts, he noted. Those underperforming services can be readily identified using a flame graph capability that Nobl9 has built into the platform, said Singer.
As application environments have become more complex, tracking the impact that individual software components are having on specific services and processes has become more challenging. Nobl9 enables DevOps teams to programmatically define SLOs that make it simpler to identify degradations in any application service that has been assigned an SLO.
That platform can provide that capability via integrations with DevOps tools and platforms from, for example, Datadog, Dynatrace, Splunk, Google BigQuery and Amazon CloudWatch, which provide access to telemetry data.
That’s critical, especially for organizations that have to comply with service level agreements (SLAs), that require application services to meet specific availability and performance requirements. Many DevOps teams deliberately set higher SLOs to ensure those SLA requirements are met or exceeded, said Singer.
Ultimately, the challenge organizations face is finding a way to achieve and maintain SLOs as efficiently as possible versus having to always over-provision infrastructure resources. Every service has an application programming interface (API) that in one way or another is limited by the physical infrastructure it accesses, noted Singer.
It’s not clear how many DevOps teams are tracking SLOs, but given how dependent organizations are on software to drive revenue, there is a lot more interest in, for example, understanding how application latency might be impacting the business. That requires DevOps teams to be able to track not just whether an application is available, but also the levels of service made available at various points of the business cycle.
Tracking DevOps Research and Assessment (DORA) metrics may be an important method for measuring productivity, however, it doesn’t provide enough meaningful insights into the return on investment (ROI) that organizations are making in software. The only way to achieve that goal is to be able to identify which application services are most critical to the business, especially in an era where more software than ever is consuming cloud infrastructure resources on demand.
The one certain thing is that if business leaders are not already asking for that level of insight, it’s only a matter of time before they do.
