In Application Monitoring, what is the application?

Thoughts on NADOG meetup @ NYC

Last night, at NADOG meetup, Instana’s CEO and co-founder, Mirko Novakovic, introduced Instana’s APM tool. He talked about DevOps KPIs and how releasing faster actually improves software quality — with some fascinating evidence generated by Instana.

He also mentioned one of the challenges of monitoring: no one agrees on the definition of application.

This is a challenge because different users expect to see different things monitored when they think ”application monitoring”.

For a developer it could be just the micro-service she or he are working on in the dev environment.

For a performance test it could be just the services in the test environment.

For the production environment it’s.. well.. the production environment.

What is the application? Is it every service? is it all the services? just a subset of them?

In order to address this challenge, Instana added a feature that they call “Application Perspective” to their software. This feature, according to their blog, enables users to create tailored views of their monitoring data, so it reflects only the part that is interesting for them.

I think this is a great idea that is worth looking into.

Why is it so hard to agree on what the application is?

As Instana put it — the application is a matter of perspective. Everyone looks at it different. It’s subjective.

I think it’s subjective because the people that work on the same application throughout its delivery have different business needs. Some of them need to develop. Others care about security. Some want to make sure there are no typos in the UI. Some want to test performance. Others want to handle the critical life-threatening crisis that is happening right now in a customer’s environment.

Each one of them sees the application a bit different. Some focus on one or more services. Others look at an entire production environment.

But it’s the same application. It’s just the business perspective that is completely different

This changing set of components that each user thinks IS the application is what moves between the different stages of the application delivery. It is therefore important to understand it. Especially if you are working on continuous application delivery.

Giving this set of components a name is a great first step. “Application Perspective” is how Instana calls it.

Or Environment

I call it environment. You probably know what “development environment” means. You will not be confused if I talk to you about “test environments”. You will surely understand what I mean by “production environment”.

This environment is what contains your applications or services, or a subset of them, and also the infrastructure they are on.

All the troublemakers.. if you look at it from a monitoring point of view :)

Whatever is in the scope of this environment, of your business need, is what should be monitored.

What happens if you monitor environments instead of arbitrary applications and infrastructure?

When you monitor environments you actually monitor a group of applications/services on some infrastructure. It’s no different than monitoring everything your APM tool discovers.

Except for one thing:

When you monitor an environment, you know what you monitor

You know why this group of components was spun up and deployed (for example, for a production environment upgrade).

You know what triggered it (for example, the pipeline. With build X).

You know when in the continuous application delivery it happened. And you have the context (for example, this build X started from code change Y. And actually, similar issues were detected in the performance testing environment right before deploying to production)

Getting ready for AI

As AI gets more mature, it’s easy to imagine how traditional management systems give way to tools that automatically generate meaningful data, and do kick-ass things with it.

When the data that your monitoring and logging systems collect is connected to your business process it instantly becomes more meaningful. And therefore more powerful.

Having the environment information (why, what, when, context..) makes it possible to use monitoring and logging data to connect the dots.

What happens if you also connect this data to the teams that use these environments? to cost data? I think it opens a world of possibilities.

What do you think?