In this 3 part series, I will explore, contrast, and discuss the differences as well as the history of APM and the meteoric rise of Modern Observability, why these two are related but simultaneously are vastly different in outcome. Indeed, Modern Observability is disrupting the world, and organizations doing it right are realizing massive gains in innovation, reaping the benefits of higher performance and optimization across numerous dimensions including:

■ IT governance

■ Revenue growth

■ Vendor cost reduction

■ Tool Consolidation

■ DevOps toil and churn

■ Application performance and customer experiences

■ Reliability and Security

■ Employee satisfaction

■ Data Science and Business Analytics

■ AI-controlled automation (AIOps)

Modern Observability is becoming the foundation upon which organizations are able to reduce the toil and churn associated with capital spending across initiatives such as Cloud Migrations, App Modernization, Digital Transformation, and AIOps by leveraging new methodologies such as Observability-Driven-Development (ODD).

Traditional APM is a mature, vendor-led industry, and was built at a time when the world was developing monolithic, 3-tier architectures and when software was typically released once or twice a year. APM is a closed ecosystem, with patented protocols and agents which are deployed to run on every node, injected into runtimes with startup parameters, and have little to no impact on how software is designed or developed.

This is a good thing, right?

In contrast to Modern Observability, and for organizations moving to the cloud, APM is loaded with hidden costs and unintended consequences. From a process perspective, APM does not live within the developer ecosystem and has historically been funded by Ops teams or DevOps/SRE groups that have largely been out of the immediate workstream of software development. This nuance means developers have no real ownership interest in APM and don't feel compelled in taking responsibility for declaring what it means to make something "observable." What enterprises desire most are reliable pipelines of telemetry that provide accurate data inferring the internal state of systems including usage and behavioral insights of end-users, code execution, infrastructure health, and overall performance. Most developers have been poor adopters of APM.

A major characteristic of Modern Observability is in how it becomes designed into the fabric of the applications, services, and infrastructure by DevOps teams, implemented through models such as GitOps, which in turn provides numerous benefits to organizations that legacy APM really does not align to. It is within this point of view or context that I base my opinions on throughout this series. Many organizations still relying on APM vendors will struggle to increase the intrinsic value of data within the organization. It's my firm argument that the most important attribute of Modern Observability lies in its "programmable" nature, whereby the acquisition of telemetry becomes woven into the fabric of developing software and the services offered by anyone competing in this global software-driven economy.

There are many other dimensions of contrast, but I personally believe this to be the most important with respect to organizations embracing digital transformation, or for those that just want to improve maturity, growth, and innovation, or anyone wishing to own their own destiny when it comes to data intelligence.

In the next installment (Part 2) of this series, we dive into the history of APM and how it became a 6 Billion USD market and explore some of the challenges that come with APM.