Why Developers Need Their Own Observability

“Why did it do that?”

That’s the question software developers repeat all too frequently. Something went wrong with the app they were working on. Did they introduce a bug? Was it something a colleague changed? Or perhaps it was some kind of infrastructure issue somewhere between the frontend and the backend?

In the bad, old waterfall days, developers worked in boxes. Not only were Dev, test and Ops entirely separate endeavors, but even within Dev, frontend and backend teams worked largely independently of each other.

No more. In today’s distributed, cloud native world, every software component is intertwined in a complex web of dependencies with many others, as are the teams that work on them.

In this rapidly changing, interconnected environment, developers need answers, not only to why their app might be performing poorly, but how to fix it. And to get those answers, they need observability.

Not the Observability You Might Think

Observability is all the rage in Ops circles. Equip all the software to generate streams of telemetry data, and then use one of dozens of application performance management (APM) and infrastructure management or IT operations management (ITOM) tools to make sense of all that data.

The goal of operators’ and site reliability engineers’ observability efforts are straightforward: Aggregate logs and other telemetry, detect threats, monitor application and infrastructure performance, detect anomalies in behavior, prioritize those anomalies, identify their root causes and route discovered problems to their underlying owner.

Basically, operators want to keep everything up and running — an important goal but not one that developers may share.

Developers require observability as well, but for different reasons. Today’s developers are responsible for the success of the code they deploy. As a result, they need ongoing visibility into how the code they’re working on will behave in production.

Unlike operations-focused observability tooling, developer-focused observability focuses on issues that matter to developers, like document object model (DOM) events, API behavior, detecting bad code patterns and smells, identifying problematic lines of code and test coverage.

Observability, therefore, means something different to developers than operators, because developers want to look at application telemetry data in different ways to help them solve code-related problems.

Developers Need Observability Built for Their Needs

Because today’s developers work on complex distributed applications, they need observability that provides insight into how such applications behave. In particular, developers require:

• End-to-end traceability: Developers must be able to trace a user interaction or other event from the frontend to the backend.
• Visibility into API behavior: APIs are the glue that holds modern software together. Building APIs is thus a central role of the developer. How well APIs behave depends on both the code exposing the API as well as the software that consumes them. Developers need to have visibility into both sides of this equation.
• Event trails, aka “breadcrumbs”: Tracking down problems can be a whodunit mystery. Stepping through the events that led to a problem can identify its cause — and its fix.
• Version changes and responsible parties: In many cases, a problem crops up that is the result of some other developer’s work. Keeping track of who’s doing what and how their changes affect the current state of the software landscape are essential. Developers want to quickly assess the issue and either resolve it or route it to the responsible party.
• Release tracking: Developers need to keep track of both new issues and regressions for each release. They must also track issue resolutions and monitor application health.
• Test coverage: Developers also require test cases to ensure their code is reliable. In addition, if some code snippet never runs, then there’s no way to test it. The presence of such code also reveals some kind of logic error that prevents the code from running.
• Visibility into both pre-release and post-release behavior: Developers typically code and test in a pre-release environment. They require pre-release observability to ensure their app works in this environment. Only then do they push code to production. Afterward, they still need to monitor and observe the app so they know it works post-release, because other developers continue to push code that could affect their own.

Clearly, the observability needs of developers are quite different from the needs of operators. Without the benefits of developer-focused observability, developers will be less productive and produce poorer code overall.

Worst of all, without sufficient observability, developers will stumble upon issues as though they were walking around in the dark — issues that will trip them up and detract from the creative flow that developers need to do their jobs well

The Intellyx Take

We’ve all run into slow-loading pages and other performance issues, as well as the dreaded HTTP 500 Internal Server Error — an otherwise empty web page that indicates that something went wrong somewhere.

Nobody wants to see such errors — developers least of all. Their lack of information is matched only by the urgency of the fix.

Without the visibility a developer observability tool can provide, developers would remain in the dark. Such tools should be on every development team’s shopping list.

Unfortunately, shopping for a developer-focused observability tool can be tricky. APM and ITOM are well-defined categories, with established vendors who offer mature products. Not so with developer observability.

One of the few vendors pioneering this space is Sentry, but one vendor doesn’t make a market. Given the significance of developer observability, however, it won’t be long until other vendors crowd into this important segment.