The New Stack article for Sentry by Jason Bloomberg
“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.
Comments
Comments are closed.