You might have heard about application performance monitoring, or APM.
And you might have also heard about observability.
And you may have heard that observability is an evolution of APM. But observability is not a new name for APM, or even an evolution of APM.
And the reason is APM delivers debugging of applications, whereas observability delivers an understanding of applications.
Let me explain.
Let's use a real world example that happens more often than people realize.
We're going to take an application, we'll call it A.
And A interacts with a couple of backend systems, and interacts with the database,
and interacts with the messaging system, and it interacts with the transaction system.
And A has an APM agent that sits inside its code and monitors not just what's happening here,
but also the response times of all the backend system calls that go out of A.
We're going to introduce a second application now, we're going to magically call it application B.
And application B also interacts with the same database that A does.
And somewhere along the way, a new version of B is released,
and instead of calling 10 database requests per second, he's going to start making 10 million database calls every second.
Now, that's not going to kill the database, but it's going to make it hard for the database to keep up with everybody's requests at the same time.
And so we're going to call B now a "rogue" application because B is misbehaving.
And actually B is causing problems for A's users because they're starting to see slowdowns in their requests through application A.
But the APM code here in A doesn't know about B.
All it knows is that it has response times to the three systems.
And in reality, in this situation, it's going to see good response time back from the database server.
It's just saying take a long time for the data to catch up and get to the end user.
In order to really understand what's going on here, you have to have context and understanding of the entire system.
And that's where observability comes in.
Because instead of having an agent sitting in A's code,
instead, observability is going to put a sensor everywhere that is needed, in all the systems throughout the environment.
And by flipping the context from A's perspective to the databases perspective,
you're going to be able to see that the database is being mismanaged by calls from B.
And now you can actually push the problem back to B, see that there was a change, and get a rollback in the change.
So you solved A's user problems by rolling back B's code.
And that's what observability really gives you, is this idea of context throughout the entire system.
And that's the power of understanding.
But wait, there's more.
Because if you think about two applications or two services and one shared resource,
as you move into more distributed microservices architectures and deal with dozens or hundreds or even thousands of services,
all tied together, interacting with each other in very different ways,
the only way to understand what's going on inside all of those is to have an observability sensor everywhere it is.
So as you move from monolithic applications to more microservices architectures,
the idea is you're responsible for all the pieces of your code, but also in understanding how they all work together.
And also in understanding how all of your code works together with everyone else's code
and all the other systems that are part of the application environment.
And that's delivering the understanding needed to deliver high-performance applications.
And that's why you need observability.
Thanks for watching.
Please remember to like this video and subscribe to this channel so we can continue to bring you content that matters to you.