Application performance monitoring (APM) has become one of the key strategies adopted by IT teams and application owners in today’s era of digital business services. Application downtime has always been considered adverse to business productivity. But in today’s digital economy, what is becoming equally dreadful is application slowdown. When an application is slow, the end user’s experience accessing the application is negatively affected leaving a dent on the business in terms of commercial loss and brand damage.
As organizations start looking for application performance monitoring solutions, they need to understand what capabilities would be useful to diagnose and troubleshoot performance slowdowns and application failures. This is where the water gets murky.
While there are many industry guidelines for what an APM solution is and what capabilities it should comprise, what one fails to see is whether those guidelines are applicable for the specific application that one wants to monitor.
Understanding Different Application Types
There are various types of applications being used in IT today. Broadly, these can be characterized as follows:
|Web applications||Typically, custom applications built on technologies such as Java, .NET, PHP, Python, Node.js, Rails, etc.|
|Packaged enterprise applications||SAP, Siebel, PeopleSoft, SharePoint, Atlassian Confluence, Salesforce, etc.|
|Desktop-based applications||Microsoft Office, QuickBooks, Graphics tools, etc.|
|Mobile applications||Applications natively built to run on mobile platforms|
|Middleware applications||Application servers, message queues|
|Infrastructure applications||Active Directory, DNS, DHCP, etc.|
|VDI applications||Citrix, VMware Horizon, Microsoft RDS|
Why One Size Does Not Fit All
Monitoring of an application should broadly cover health, availability, response time, and usage. While these are common categories of metrics that apply to all types of applications, the detailed performance metrics in each category are dependent on the nature and domain of the application. Metrics that apply for SAP may not apply for a .NET-based web application. Performance monitoring of a database would be entirely different from VDI application (such as Citrix). For effective monitoring, performance metrics gathered should be domain-specific and must provide enough intelligence for the respective domain administrators and helpdesks, assisting them to detect and rectify problems quickly.
Even the methods used for performance data collection will be vastly different from one application type to another. This means the same monitoring mechanism cannot be generalized and applied to any application, which, in turn, implies that the monitoring capabilities that are needed for each application may be different. Organizations must understand this while looking for application performance monitoring solutions.
When evaluating different monitoring solutions, consider the domain expertise built into each solution you are considering. Generic metrics that apply across application types are often insufficient to identify the root cause of problems. Likewise, when analyzing analyst reports, try to glean what type of application the analysis has focused on. For instance, if you look at the Gartner Magic Quadrant for APM, its focus is mainly on web servers, Java and .NET application servers, and applications that process HTTP/S transactions. Hence, this analysis is not relevant if you are looking to monitor Citrix and VDI infrastructures, to monitor SAP, or if you are seeking a unified console to monitor your database servers.
Every application is not the same and every APM solution is not the same. Understand the ideal use cases for each technology, otherwise, you will end up comparing apples and oranges!
Similarities Exist in Principle, But Effective Performance Monitoring Demands Domain Expertise
The three dimensions that Gartner mandates as functional requirements of an APM tool (Digital Experience Monitoring; Application Discovery, Tracing and Diagnostics; Artificial Intelligence for IT Operations) largely apply for any type of application.
- Whether you are monitoring SAP or Exchange, or Citrix, you still need to track the digital user experience. Synthetic monitoring and real user monitoring are still applicable.
- Automated discovery and dependency mapping is still a requirement for any type of application. However, tracing of transactions may not always be possible outside of the web application context. The extent of visibility into transaction processing depends on the APIs exposed by the different technologies.
- Analysis of performance patterns and trends, detection of anomalies using AI techniques/machine learning is still applicable for all the different types of applications.
The missing functional requirement above is domain expertise. An in-depth understanding of how an application functions, what protocols it uses, what other applications it interacts with (i.e., has dependencies with), its internal design (e.g., single threaded or multi-threaded), what are the common failure modes of the application, etc. are some of the key criteria you have to consider when determining if a monitoring solution will address your specific needs.
In summary, all applications are NOT the same. And one single monitoring solution may not fit all the needs. Understand the type of application you want to monitor. Understand the scope of monitoring that you need. Then, evaluate the type of solution with monitoring domain expertise you need for your environment.
By clearly understanding the scope of your digital business services and the underpinning ecosystems needed to support them, you can begin to establish boundaries that will allow you evaluate the type of application monitoring solution that is the best fit for your environment.