Wikipedia does a nice job of defining Application Performance Management (APM) as: the monitoring and managing of performance and availability of software applications. APM strives to detect and diagnose application performance problems to maintain an expected level of service.

The write-up in Wikipedia goes on to describe “current issues” saying: “Two challenges for implementing APM are (1) it can be difficult to instrument an application to monitor application performance, especially among components of an application, and (2) Distributed, virtual and cloud-based applications pose a unique challenge for application performance monitoring because most of the key system components are no longer hosted on a single machine. Each function is now likely to have been designed as an Internet service that runs on multiple virtualized systems. The applications themselves are very likely to be moving from one system to another to meet service level objectives and deal with momentary outages.”

Wikipedia describes a very important issue. Today, no application is a standalone and in reality is very likely a composition of multiple applications running on different virtual servers to provide a function like, for example, ordering a book and getting it shipped. This function can be composed of 10 different applications, one that knows the inventory, one that handles shopping and payment, and then another that manages the shipping. All these applications together provide a service – buying a book – and it is the performance and availability of that service that the business cares about. This distinction is so important that it deserves a new name. I call it "Service Performance Management" as opposed to Application Performance Management.

Before we delve too deeply into differences between Application Performance Management and Service Performance Management, let's first look at some of the strengths of APM.

Most APM tools monitor business transactions, both end-to-end and between individual application components. This can serve to measure end-user response times of transactions. It can also show a breakdown of the transaction on the application components that support it, going as deep as the response time of a software method executed in a line of code on a specific tier for a specific transaction. These types of APM tools are powerful in analyzing and debugging issues from a specific transaction level down to the specific application code.

However, the downside of such an approach is that each of these tools is inherently specific to a small number of applications – usually web applications running on Java or .Net – and are agent-based. To capture a complete view of all applications, often multiple tools need to be deployed. Such an undertaking incurs significant management overhead and carries with it the risk that all elements comprising a business service – application and supporting infrastructure components – may not be completely discovered and monitored, thus leaving gaps in management visibility.

While APM provides application-level visibility, Service Performance Management (SPM) provides additional visibility into the complex relationships between applications that provide the service by combining application-centric data from APM systems with detailed information of the supporting infrastructure components from other monitoring tools. This creates a holistic cross-domain view of the availability and performance of business services.

SPM presents the “whole” picture, incorporating both the complex network of applications that are needed to provide the service and the entire supporting infrastructure, such as storage, web servers, database servers, and networking gear, which together comprising the business service.

In addition, Service Performance Management is not limited to a narrow range of applications but rather is capable of discovering the entire service so that monitoring and management can be targeted specifically at what the end-user cares about: availability and performance of the consumed service. In addition to the obvious visibility this provides to IT executives and operators, it also allows CIOs to present objectively quantifiable information on the health of critical services to their business peers, thereby assisting in the alignment of IT and the business.

Choosing What is Right for You

The good news is that IT professionals investigating the use of APM and SPM tools are not confronted with the need to make a Hosbon's choice, as both approaches complement one another. APM tools provide deep visibility into the application while SPM tools provide a broad view of the applications and supporting infrastructure that define a business service. With these working together, IT professionals can achieve complete visibility into the business service while having the option to drill deep into applications for debugging purposes.

How do you choose among the many options the one which is right one to start with? If your critical issue is a number of web applications where most of the issues are related to the application-level code, then APM tools would be the best choice. If, however, you have an issue with service availability and performance and need a complete view into very complex applications that interconnect to provide the service and supporting infrastructure, then an SPM tool such as Neebula would be a good choice to start with.

So, in many cases, the optimal approach is a combination of both, using APM tools for the deep-dive view on the application-to-application transactions status that is correlated with end-user experience, along with Service Performance Management tools for an overall view on service status across all technology domains, including non web-based applications. This combination enables IT operations to provide an unparalleled level of service availability to their end users.

Ariel Gordon is VP of Products and Co-Founder of Neebula