APM vs Observability: Both-and, not either-or

I'll start this, the third and final entry in my series on APM and Observability, which was originally inspired by my contribution to an APMdigest article, by once again pointing out that APM tools can be built with observability in mind. Many are, in fact. And the ones that aren’t don’t turn into a different type of tool. In my experience, it's more that there's a difference of mindset.

Once again I want to caveat my delineation between “APM” and “Observability” by saying  

1. It’s a really bad premise. These two things are so intertwined that almost any statement about one could be true of the other, given a specific vendor implementation.

2. I’m never the less sticking with it in order to highlight overarching trends, variations, and differences.  

For reference (and to save you re-reading two other blog posts):  

• “APM” implies a system where data is requested; that often focuses on known-unknowns; where correlation between separate technologies is often manual; and where the “signals” – the aspects which identify performance and failures – are discrete and different between technical domains.  

• “Observability” implies a system where data is emitted; that often focuses on unknown-unknowns; where correlation is automated; and where the golden signals (latency, traffic, errors, and saturation) are used to identify performance and failures across technical domains.  

Mindset matters more than labels

Imagine you have a specific problem in front of you. After research and analysis, you come to the conclusion that you need a new tool to solve this problem. If the tool you pick is APM, it means you had one type of mindset about your problem (and your needs, and the specific context, etc.). If, on the other hand, an observability-centric solution is what you selected, then you had a different mindset.

If you decided to solve the problem with a typical APM tool, it means you were focused requesting status of the component elements as needed, with less emphasis on what was happening under the hood. The data collected is more centered on when application had an issue, and what the experience of that impact was – not what line of code or sub-system failed, but how that issue bubbled up and manifested in terms of user experience. Only after those questions are answered would additional insight into the technical aspects be included.

That's not to say that APM tools don't test or look at sub-components of a website. As I called out in part 6 of the APMdigest series, “Modern, robust APM tools can test everything from individual database queries to API calls and beyond. It's just that the focus is on how those elements are experienced from an external point of view, rather than how it works from inside the application (or website, or whatever) itself.”

Observability starts with the unknowns

Continuing along that line of thinking from the APMdigest article: “On the other side of the fence, if your decision was to address the imaginary issue with a solution that was observability-centric, it would indicate that your first concern was from an inside-the-code perspective; and that you were worried not so much about predictable ways the application (or website, or whatever) could fail, but rather on all the unpredictable things that might happen down the road. The so-called "black swan" events.”

Can one tool do both?

Do organizations need both APM and observability tools, or can they get everything in one tool?

While it's possible for APM tools to have an observability-focused design and feature set, providing a best-of-both-worlds experience, most don't. In part 8 of the APMdigest series I pointed out, “And even the solutions that are a blend of both worlds — usually the result of acquired companies and merged toolsets — end up focusing on more of one than the other, with the lesser of the two simply there to provide context to the other or, worse, to be little more than box-checkers to pass an RFP.

So, putting aside my pedantic philosophizing, yes, companies will probably need both. More specifically, different teams within an organization will require the capabilities of one more than the other.”

Different tools for different roles

Driving deeper into the meat of the issue, it becomes clear that APM and observability tools are used by different roles. Furthermore, the selection of the solution will largely depend on the types of problems that the role most often needs to fix. For roles and teams where the critical piece is knowing when something (an application, website, or other system) starts failing, and the points at which (from the user's perspective) the failure manifests, APM tools are the preferred choice. This extends to major subcomponents, such as databases and APIs, and even to significant dependencies, like DNS.

Meanwhile, if the role/team's focus is on the internals — code execution and log messages — then so-called "observability tools" would be the preferred option.

Compare what you can monitor with APM vs IPM

‍