I met several customers in the past few weeks who are evaluating Application Performance Management (APM) solution. They are facing a lot of challenges with their existing investments in old generation of APM solution. In this blog, I will outline some of the shortcomings with APM 1.0 tools that make them unfit for today’s applications.

What is APM 1.0

Customers have been managing application performance since early days of mainframe evolution. However, Application Performance Management as a discipline has gained popularity in the past decade.

Let me first introduce what I mean by APM 1.0. The enterprise applications and technologies such as Java have evolved in past two decades. The APM 1.0 tools were invented more than a decade back and they provided great benefits to resolve application issues that were prevalent with the early versions of Java and .NET technologies. However Java/.NET application servers have become mature and do not have those challenges any more. Also enterprise application architecture and technologies have changed drastically and the APM 1.0 tools have not kept up. The following figure shows the evolution of enterprise Java in the past 15 years and when APM 1.0 and APM 2.0 tools have started emerging.

Following are few challenges with the APM 1.0 tools that you will run into when trying to manage your enterprise applications.

Challenge 1: Not enough focus on end-user or visibility for business critical transactions

The application owner and the application support team primarily cares about the user experience and service level delivered by their applications. APM 1.0 tools were primarily built to monitor applications from an application infrastructure perspective.

These tools lack the capabilities to monitor applications from real user perspective and help you isolate application issues whether it is caused by the network, load balancers, ADNs such as Akamai, or the application, database, etc. Some of these solutions were quick to add some basic end-user monitoring capabilities such as synthetic monitoring. However an application support personnel has to switch between multiple consoles and depend on manual correlation between end-user monitoring and application deep dive monitoring tools.

These tools do not allow you to track a real user request to the line of the code. That means you are blind-sighted when users are impacted and struggle to find what is causing the application failure.

Challenge 2: Built for Development and not suitable for production monitoring

APM 1.0 deep-dive monitoring tools were primarily built to diagnose issues during the application development lifecycle. These tools morphed into production deep-dive monitoring tools when the need arose for APM in production environments.  So, These tools were not optimized for production monitoring and hence require a lot of effort to tune for production.

First off, the complexities of agent installation and configuration hinder deployment in production environment.  Second, these tools usually require configuration changes every time new application code is rolled out.

Most damagingly, they have high overhead on application performance and do not scale beyond 100-150 application servers. This means that most customers use these in a test environment or enable deep-dive monitoring retroactively after an application failure -  assuming the problem will recur.

Finally, these tools do not provide operation friendly UIs and because they were originally built for developers.

Challenge 3: High Cost of Ownership

As I alluded earlier, the old generation APM tools are very complex to configure because these require application knowledge, manual instrumentation and complex agent deployment. Hence expensive consultants are required to deploy and configure and maintain these tools. These tools also have multiple consoles - adding to total cost of ownership. Some customers told me that they spend a lot of time managing these APM tools rather than being able to manage their applications.

Conclusion: A Poor fit for today’s applications

These tools were built more than a decade back, and have not evolved much although the application architecture, technologies and methodologies have gone though drastic changes.

Many of the customers whom I met were of the opinion that they spend more time managing the APM solution then managing their applications. If you use any of the APM 1.0 tools, and try to manage a modern application, you are likely in the same boat. Here are some customer expectations for a modern  APM solution:

• It reduces your MTTR by quickly pinpointing business-critical issues with always-on, user-centric, deep application visibility
• Non-Invasive solution that requires no changes to application code, does not require manual instrumentation and auto-discovers your transactions, frame works, etc
• It provides Quick Time to Value and Ease of use with a single, integrated APM console
• Purpose-built for cloud applications

APM 1.0 tools certainly cannot satisfy these needs.  In the next blog, I will discuss how an APM 2.0 solution like BMC Application Management addresses the challenges with APM 1.0 products and help you manage applications better thus improving customer satisfaction and resulting in better bottomline.