In an industry where every company is competing to be the best, if your application is giving users problems, they might not hesitate to ditch you and go to your competitors who do have a well-performing app. Companies that cannot provide their customers and users with satisfying experiences will lose out on business. This is why APM (Application Performance Management) is more important than ever.
APM provides organizations with insights into performance that can them help expose bottlenecks and dependencies within application code, explained Amena Siddiqi, product marketing director of SteelCentral APM at Riverbed. This allows companies to “find and fix issues before users become aware of them and well before the business is impacted.”
RELATED CONTENT: A guide to APM tools
According to Siddiqi, APM enables organizations to achieve many things, such as shift left, perform code audits, understand feature usage and usability, map business dependencies and impact, and accelerate the application life cycle.
Pete Abrams, chief operating officer of Instana, explained that APM is becoming increasingly important as more companies adopt CI/CD practices. “As DevOps team shift to a continuous deployment model there is a significant increase in the amount of dynamism in production. More software is updated or added more frequently on more infrastructure. It’s great for solving business problems but difficult on monitoring tools that were designed for a much slower rate of change.”
However, the traditional method of APM is no longer sufficient. Traditionally, when developers and operations teams were more siloed, developers would write code and send it off to operations teams, after which point the developer might not see that code, explained Tal Weiss, CTO of OverOps. In the past, APM tools were traditionally only used by operations teams, and they often were used as a means for operations teams to point blame at the developers when things went wrong, Weiss said.
According to Weiss, as a result of the DevOps movement, development and operations have become less siloed, and APM tools need to change to reflect that.
Now, APM tools will need to “go from serving one audience to serving multiple audiences with different needs and different levels of understanding and depths of understanding of that company’s codebase and anything that goes into it,” said Weiss.
This poses a challenge in terms of APM tool adoption that organizations need to figure out how to overcome in order to effectively use APM, Weiss explained.
According to Weiss, power has shifted in a dramatic way to developers in the past two years. Developers now have much more control in choosing the infrastructure that code runs in and the tooling used. APM vendors will have to respond to this shift by keeping developers in mind when developing their tooling. He believes that APM solutions are currently lagging behind with that.
Weiss added that APM tools that are still primarily focused on operations teams struggle in gaining widespread adoption in enterprises where the developers have certain expectations they want met.
Every team involved with application delivery has use cases requiring the data and information that would be provided by an APM tools, Instana’s Abrams explained. For example, an engineering team can use APM to plan and monitor the capacity of their platform and troubleshoot issues, while a development team might want to utilize APM to understand upstream and downstream calls, errors including context and stack traces, and see timings on calls to databases or other subsystems, the company explained.
Another challenge organizations are facing with APM is that there is so much diversity in terms of the kinds of tools, languages, and frameworks that teams use to build applications, said Daniel Spoonhower, CTO and co-founder of LightStep. “One challenge for APM is how a single tool can provide visibility across all of those different languages and frameworks,” he said. “The point of an APM tool is to understand the bigger picture of the whole application, and especially a whole application as it’s used and viewed by the users and the customers of that organization. And so it’s really important to have a standard set of both methods and tools for understanding what’s happening across an organization. As the organization chooses and becomes more fragmented in the way its application is built, that’ll create some challenges in APM itself.”
Spoonhower believes that organizations can overcome this challenge with top-down decision making. “I think if an organization can make those determinations it sort of has to come from the top down. If they can do that, it’ll go a long way for the organization as a whole moving more quickly.”
According to Siddiqi, APM is not well-suited to all types of applications, for example components where you have no control over their back-end components, such as SaaS applications or Office 365.
Another use case not supported by APM would be a Citrix app running on a virtual desktop where the code cannot be instrumented. “For these reasons, a majority of business applications are simply not monitored at all,” said Siddiqi.
Another shortcoming of APM is that all monitoring systems could be showing that everything is fine, yet help desk tickets are still being logged, Siddiqi explained. “You need a way to see what users actually see when they use these applications, with visibility into the device itself—the mobile phone, PC, laptop or any other device that your internal users are using to serve your customers,” said Siddiqi.
Another issue is that many APM vendors are limited in their data collection. They typically are forced to resort to sampling or snapshotting based on errors. “This puts APM at a disadvantage when it comes to troubleshooting. Oftentimes, the data simply isn’t there to reconstruct and diagnose an issue,” said Siddiqi.
Going forward, APM vendors will need to start incorporating AI and machine learning into APM by incorporating AIOps into company strategies, Siddiqi said.
Another trend that is being seen is the commoditization of distributed tracing, Siddiqi explained. “This is often positioned as a war between traditional APM and OpenTracing but it’s really not an ‘either/or’ but rather a ‘better together.’” OpenTracing is a CNCF project that includes a set of vendor-neutral APIs and instrumentation that is used for distributed tracing.
“This artificial divide can be bridged by enhancing application tracing with the context exposed by OpenTracing to produce a richer distributed trace,” said Siddiqi.
Siddiqi also explained that while open-source options may look attractive, organizations need to choose sustainable APM strategies that are managed, curated, supported, and universal.
Changes in architecture require changes in APM
In order to survive, LightStep’s Spoonhower believes that APM providers will need to rethink tooling. A lot of the tools that are out there today are geared toward more monolithic architectures, but as those architectures get broken up into more and more pieces, the APM tools will need to change to accommodate that switch.
“Changes around architectures are definitely forcing a lot of organizations to think differently about their tools and about their APM solution,” said Spoonhower.
Specifically, breaking up applications into microservices or serverless tends to increase the volume of data coming out of those application. APM tools will need to be able to scale and accommodate that increase in data volume in order to maintain the same level of visibility.
“But at the same time, there’s a lot of cost to that and that cost is scaling in a way that’s not necessarily proportional to their business,” said Spoonhower. “So that’s creating a lot of pressure on those teams and organizations to really think about the way that they’re using that data and the way that they’re gathering and analyzing that data.”
Automation will become even more important for keeping up with continuous development
Instana’s Abrams believes that APM will need to change to incorporate more automation. “Any manual interaction slows down the development cycle, and that’s true of monitoring as well,” Abrams said. “APM has to adjust to the new normal, distributed applications, a polyglot of languages, continuous deployment, all built around extremely dynamic applications. Even simple configuration can get in the way, but APM tools must move to an automatic approach that can deal with the dynamism of the modern environment.”
According to Abrams, conventional APM tools need to be extensively configured and optimized to monitor applications effectively. “They require too much manual work to even get started. Take an application map, as an example,” said Abrams. “Manual mapping is not only error prone, it is also likely to be obsolete before the first set of data is reported. Once you inject faster change associated with CI/CD, manual tools actually slow down every single cycle.”
Manual APM struggles to deal with the dynamic environments created by microservices and containers, Abrams said. This ultimately leaves “a large hole in APM strategies everywhere.”
