In APMdigest's exclusive interview, Doug Roberts, Director of Enterprise Products at Fluke Networks, discusses Application Aware Network Performance Management (AANPM) and its relation to — and difference from — Application Performance Management (APM) and traditional Network Performance Management (NPM).
APM: What is AANPM? How is it different from traditional NPM?
DR: Application Aware Network Performance Management (AANPM) is an approach to monitoring, troubleshooting and analyzing both networks and application systems. Whereas traditional Network Performance Management (NPM) focuses on monitoring the health of devices, AANPM takes a more holistic view to address the complex issues facing business application systems today.
There is a real need for management platforms to broaden their visibility to include both network and application analytics. Data must be correlated to enable network engineers to quickly locate problems, regardless of their source — network or server, wired or wireless, physical or virtual, local or remote, real-time or back-in-time, client or cloud.
APM: Are AANPM and Network Performance Monitoring and Diagnostics (NPMD) referring to the same tool?
DR: While different analyst firms use different terms, they all essentially boil down to the same thing. The traditional NPM approach of monitoring the health of a network endpoint and its traffic/utilization is no longer enough. When you see ANPM, AANPM or NPMD they are all referring to the same technological leap forward: network monitoring tools that understand the applications being delivered on the network and the quality of that delivery.
APM: Explain the difference between APM and AANPM.
DR: While both APM and AANPM seek to answer the question of why performance is slow, they are typically targeted at different users.
An application owner or DevOps team needs deep visibility into where performance bottlenecks are occurring within an application, perhaps even down to the module or line of code. This is typically accomplished by instrumenting the application server with an agent to monitor application behavior. These APM tools may have some understanding of the network, but not where or why there is a network problem. The agent-based nature of these approaches often limits what applications can be monitored by an APM solution (such as Java, .Net, Ruby, PHP etc.).
On the other hand, network teams want to quickly identify whether a performance problem is actually due to either a network, server or application slowdown since they’re typically burdened with proving the network isn’t the cause. When a network issue does occur, they need to quickly identify where the problem is located and what’s contributing to it. Using AANPM tools, they can quickly see where the issue is located within the network, what the user is doing and what’s causing that network performance slowdown. This provides a complete picture of the application, the network and the actual end-user experience.
APM: Is AANPM designed to augment or replace APM?
DR: It’s a little bit of both. APM and AANPM are typically used by different IT functions to monitor different things, which means they can live side by side in the same environment, monitoring performance from different perspectives. Since APM requires agents, it is typically limited to supporting specific platforms like Java, .NET, Ruby, PHP, etc. But what about the rest of the applications in the IT environment? Because AANPM solutions inspect data as it traverses the wire, they can offer broader application performance monitoring without being tied to the specific platform on which the application is running.
Given that AANPM can provide both broad and deep visibility into application transactions, many customers find they have enough visibility into applications and networks by leveraging AANPM’s ability to identify poorly performing application behavior and transactions across the network.
Many vendors, including Fluke Networks, offer integration between APM and AANPM. While both technologies will typically monitor the same critical applications, the workflows will typically branch early to cover the distinct use cases of an APM user versus a network-focused user.
