The role of APM has traditionally been to flag issues in code that affect performance. To resolve those issues, it has been necessary to understand all the spaghetti code of a monolithic application – written by multiple developers who often do not have an overarching view of the entire application – and then deconstruct that code to get to the root cause.

But as the way software is developed has changed from monolith to microservice, the way APM assesses performance must change as well.

“One of the fundamental tenets of microservices is that you write your logic in as small a logical construct as possible, so every service should only do one thing,” said Pete Abrams, co-founder and COO at Instana, an application monitoring solution provider. “The work gets done by the messages flowing, the requests that happen between the services. The problem isn’t the code now; that’s actually quite simple. The problem will be in the overarching picture, the interaction between the services.”

So one of the new challenges for IT is that this cannot be tested adequately in a test environment. The only way to understand performance from this new architecture is in a production environment. “The modern APM solution has to understand message patterns and the dynamics between the services, and that’s a real shift [in APM],” Abrams said.

Compounding that problem is how software is deployed, in containers, and how container management software such as Kubernetes and Docker Swarm moves them around to maximize application performance. Abrams called that “structural dynamism,” the ability to manage scale and add capacity when you have more demand. He explained that “it’s really about the fluid access to the processing, and the ability to reallocate and move things around in a very ad hoc way to meet demand.”

Today’s environments aren’t as static as they used to be, when code would run in a specific virtual machine on a specific server. Requests could be easily tracked and related to performance. With containers, the code could begin running in a container on a specific server, but then be moved by the container management software to a different server to gain efficiencies. So how that service performs is more difficult to track.

“There’s another new capability needed from APM, and that is really precise correlation of exactly where every request ran,” Abrams said. “I have a need to know, need to have an overarching, hierarchical map of every request that ran through the system. You need a structural map that is constantly updating itself with the here and now.”

That’s one of the biggest differentiators of what Instana is. Its APM solution understands where all the pieces are running, and can see the impact on performance when a container is moved from one server to another. “We talk about that as continuous updating and correlation,” Abrams said.

It’s a cultural issue as well
Along with the changes in technology, organizations must undergo a cultural shift to implement this evolution in APM.

In years past, the roles of development and operations were performed in separate orbs.  APM was something purchased by and run by operations, which had large budgets for core infrastructure tools and training. As the APM tools were quite complex, organizations had to train and create experts in running the tools and understanding the system.

With the advent of and uptake in DevOps, much of the responsibility for application performance is falling to developers, who often don’t have a high-level view of the application in production. “A typical microservices application might have 300 to 500 services operating, with discrete APIs humming along, messaging to each other. That’s a lot of moving parts. But the developer doesn’t care about all of that,” Abrams said. “The developer cares about their piece. Maybe a developer had a hand in 10 of those services. The first thing you have to solve is to give them an easy way to just focus on what they care about. That is the whole point of our major new release, which we call Application Perspectives.

Yet as much as DevOps has taken hold, there remain a handful of operations people in an organization who are responsible for the quality of service of the whole application and architecture. Abrams explained, “There’s most likely a set of 10, 20 or 30 very common requests coming in to the application that are good indicators of overall service quality, the so-called core transactions to the system – the log-in transaction, the add-to-cart transaction, the checkout. Those things are easy to delineate and have to run well.”

Abrams added the transformation to DevOps and containers provide a good moment to assess tooling, to find those that leverage the new techniques and technologies. “Almost all the tools in the market were created before these words existed – DevOps, Kubernetes, containers… even cloud. Instana started from scratch, with this in mind.”