Observability adding to developer toil? Time to rethink your observability

Developer toil is the curse of all software development initiatives. All the mundane, repeatable tasks that suck up developers’ time and energy, pulling them away from the value-added work of building great software – all roll up into the definition of toil.

Eliminating (or at least, reducing) toil is therefore one of the primary goals of every software development manager. 

Sometimes toil is systemic, and the best approach is to rework the entire system in question. In such cases, the buck stops with the SREs who understand what aspects of operating the software in production are toilsome. They can recommend changes that will be more streamlined, thus reducing toil.

In other cases, the toil is inherent in the day-to-day work of the developer – especially in modern, cloud native environments where teams of developers work in parallel on interdependent microservices.

The complexity of Kubernetes environments coupled with modern infrastructure-as-code DevOps approaches give rise to all manner of busywork, adding to developer toil and slowing down the software effort.

In less dynamic environments, automation is the go-to solution for reducing toil. The best way to eliminate toil from repetitive tasks is to automate them.

For cloud native environments, however, repetitiveness is less likely to be the root cause of the toil. Instead, the complex interdependencies of the environment — not only the microservices, but the software infrastructure from build to deploy — all tend to create the busywork that slows developers down, reducing their productivity, morale, and enjoyment.

To reduce the toil in such dynamic environments, developers require visibility – visibility not only into the behavior of the software they’re working on, but also how that software interacts with everything else going on in the environment.

Fortunately, there is a type of tooling that is supposed to provide such visibility: observability platforms.

Observability tools leverage a variety of telemetry including logs, metrics, traces, and events to provide real-time insight into the behavior of the observed software. They also provide the ability to take action to resolve anomalies and other issues when they crop up.

Most observability tools on the market, however, are operators’ tools. In other words, they help operations engineers monitor and manage software in production. 

The most important characteristic of such operational observability tools, therefore, is comprehensiveness. Operators need to keep their eyes on everything, since a problem might crop up anywhere.

Given the flood of telemetry information available (especially in cloud native environments), such operational observability tooling focuses on reducing the noise — filtering the flood of data to help operators uncover the salient bits of information they need to identify and solve problems quickly.

What’s good for operators, however, doesn’t help developers reduce toil. Operational observability tools cover vast swaths of the production environment. Meanwhile developers are focused on the task at hand and just those services and interactions in the environment that are relevant to what they’re working on at the moment.

The abundance of observability tools in today’s enterprises also works at cross-purposes for developers. With such tooling, developers might find they need to work with multiple dashboards, flipping between browser tabs and navigating different query languages just to gain the visibility they require, thus leading to context switching and wasted time – two pernicious aspects of toil.

There is a regrettable irony here. Developers require better observability to reduce their toil, but the observability tools on the market actually increase such toil, because they give developers more information than they need – and often the wrong information for the particular task at hand.

As organizations move from waterfall-centric processes and monolithic software architectures to a modern, DevOps-centric cloud native paradigm, developers require tools that align with the mental models necessary for such environments.

The tools developers use must be in sync with this mental model — including the ‘you build it, you run it’ DevOps philosophy as well as the ‘cattle not pets’ principle that underlies infrastructure as code and by extension, GitOps.

Organizations must then combine this mental model with the architectural constraints of microservices development. This includes microservices’ ephemeral nature, their complex and dynamic interdependencies, and the decentralized nature of development teams working in parallel to deliver software with aggressive release cadences.

To support this developer context, teams need observability tooling designed for developers that can dynamically generate perspectives in real-time. And which aligns both with the software architecture as well as each developer’s mental models for how they work.

Chronosphere Lens running on Google Cloud provides such visibility. It stands apart from other observability tools on the market because of its focus on reducing developer toil.

Instead of providing pre-built insights based upon disparate telemetry feeds, Chronosphere Lens dynamically curates information based upon each team’s microservices in progress and their respective interdependencies.

Rather than requiring developers to context switch among dashboards, Chronosphere Lens provides an intuitive, unified view of relevant information that provides real-time insights that developers can take action upon during their current task.

Chronosphere Lens gives developers visibility into how data flows among services, enabling them to identify and resolve bottlenecks as well as issues with individual microservices. 

With Chronosphere Lens, developers can thus quickly solve functional and performance problems with the services they’re working on without adding any toil to the development process.

Because they are so essential to the proper execution of cloud native workloads, observability tools are garnering a lot of attention in the marketplace.

Most observability tools, however, focus on addressing operational issues. Such tools are a poor fit for developers and can increase their toil as they try to get such tools to address their needs.

Chronosphere Lens running on Google Cloud is a different kind of observability tool, because it focuses on the information developers need, when they need it. Operators must keep the big picture in mind, while developers need to focus on the work at hand and how it fits into everything that’s going on.

Don’t let your observability tooling add to developer toil. Use the right tool for the job and improve developer efficiency, morale, and joy.

Copyright © Intellyx BV. Chronosphere is an Intellyx customer. None of the other organizations mentioned in this article is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article.