APM vs aaNPM – Cutting Through the Marketing BS

image_pdfimage_print

Marketing_BSMarketing; mixed feelings! I’m really looking forward to the new super bowl ads (some are pure marketing genius) in a few weeks but I really dislike all of the confusion that marketing tends to create in the technology world. In todays blog post I’m going to attempt to cut through all of the marketing BS and clearly articulate the differences between APM (Application Performance Management) and aaNPM (Application Aware Network Performance Management). I’m not going to try to convince you that you need one instead of the other. This isn’t a sales pitch, it’s an education session.

Definitions

APM – Gartner has been hard at work trying to clearly define the APM space. According to Gartner, APM tools should contain the following 5 dimensions:

  • End-user experience monitoring (EUM) – (How is the application performing according to what the end user sees)
  • Runtime application architecture discovery modeling and display (A view of the logical application flow at any given point in time)
  • User-defined transaction profiling (Tracking user activity across the entire application)
  • Component deep-dive monitoring in application context (Application code execution, sql query execution, message queue behavior, etc…)
  • Analytics

aaNPM – Again, Gartner has created a definition for this market segment which you can read about here

“These solutions allow passive packet capture of network traffic and must include the following features, in addition to packet capture technology:

  • Receive and process one or more of these flow-based data sources: NetFlow, sFlow and Internet Protocol Flow Information Export (IPFIX).
  • Provide roll-ups and dashboards of collected data into business-relevant views, consisting of application-centric performance displays.
  • Monitor performance in an always-on state, and generate alarms based on manual or automatically generated thresholds.
  • Offer protocol analysis capabilities to decode and understand multiple applications, including voice, video, HTTP and database protocols. The tool must provide end-user experience information for these applications.
  • Have the ability to decrypt encrypted traffic if the proper keys are provided to the solution.”

Reality

So what do these definitions mean in real life?

APM tools are typically used by application support, operations, and development teams to rapidly identify, isolate, and repair application issues. These teams usually have a high level understanding of how networks operate but not nearly the detailed knowledge required to resolve network related issues. They live and breathe application code, integration points, and component (server, OS, VM, JVM, etc…) metrics. They call in the network team when they think there is a network issue (hopefully based upon some high level network indicators). These teams usually have no control over the network and must follow the network teams process to get a physical device connected to the network. APM tools do not help you solve network problems.

aaNPM tools are network packet sniffers by definition. The majority of these tools (NetScout, Cisco, Fluke Networks, Network Instruments, etc.) are hardware appliances that you connect to your network. They need to be connected to each segment of the network where you want to collect packets or they must be fed filtered and aggregated packet streams by NPB (Network Packet Broker) devices. aaNPM tools contain a wealth of network level details in addition to some valuable application data (EUM metrics, transaction details, and application flows). aaNPM tools help network engineers solve network problems that are manifesting themselves as application problems. aaNPM tools are not capable of solving code issues as they have no visibility into application code.

If I were on a network support team I would want to understand if applications were being impacted by network issues so I could prioritize remediation properly and have a point of reference if I was called out by an application support team.

Network and Application Team Convergence

I’ve been asked if I see network and application teams converging in a similar way that dev and ops teams are converging as a result of the DevOps movement. I have not seen this with any of the companies I get to interact with. Based on my experience working in operations at various companies in the past, network teams and application support teams think in very different ways. Is it impossible for these teams to work in unison? No, but I see it as unlikely over the next few years at least.

But what about SDN (Software Defined Networking)? I think most network engineers see SDN as a threat to their livelihood whether that is true or not. No matter the case, SDN will take a long time to make it’s way into operational use and in the mean time network and application teams will remain separate.

I hope this was helpful in cutting through the marketing spin that many vendors are using to expand their reach. When it comes right down to it, your use case may require APM, aaNPM, a combination of both, or some other technology not discussed today. Technology is made to solve problems. I highly recommend starting out by defining your problems and then exploring the best solutions available to help solve your problem.

If you’ve decided to explore your APM tool options you can try AppDynamics for free by clicking here.

  • Micheal

    Your blog may be valid for small or some cloud based startup but in real enterprise IT world convergence of network and apps performance is already happening as we speak and carries real importance in determining real business impact. There is NO marketing spin there. There are many network specific or apps performance solutions out there that gives the complete picture of application performance (network+code) in one view. End user trxs are traced with apps+network metrics in one view.

    • http://www.appdynamics.com/ Jim Hirschauer

      Hi Micheal, thanks for the comment. First let me start off by saying my experience comes from IT Operations in large enterprise environments. If you’re curious about which ones you can see them on my LinkedIn profile here… http://www.linkedin.com/profile/view?id=20303189&trk=nav_responsive_tab_profile

      Back to your comment… We are talking about two different things. Your point seems to be that there are problems that app+network tools are designed to solve. My point is that the groups responsible for the app and network domains are so very different that unified tools are rarely used.

      So my question to you is; Do you see network teams and application teams being integrated in the enterprise the same way developer and operations teams are being integrated? If so, please give examples.

      • Micheal

        Yes to yr question. Look at Tier 1 or 2 enterprise delivering critical supply chains apps, , ERPs, online/mobile order entry , B2C types Apps owners. They are all demanding convergence.

        No I am talking about one view. Network delivers application. You can’t split network out from performance management equation. In Enterprise IT,Network teams lives in their own world , OPS and DEV in their own. Solution that brings together all 3 of them on page for incident resolution , right from browser to network to data ctr (cloud) performance holds a sweet spot. Big enterprises are already moving including MSP’s like Amazon , Racks pace, MSAzure . It’s not a matter of DEV vs OPS or Network vs DevOps. It’s all in one . Those who don’t hv will probably catch on in a year or 2.

        • http://www.appdynamics.com/ Jim Hirschauer

          “You can’t split network out from performance management equation.” – You’re preaching to the choir.

          “In Enterprise IT,Network teams lives in their own world , OPS and DEV in their own.” – Absolutely right.

          “Those who don’t hv will probably catch on in a year or 2.” – This is where our opinions differ greatly. I worked in those slow moving behemoth organizations an I saw first hand how it took multiple years to make any meaningful cultural change. I’d say 3-5 years at least.

Copyright © 2014 AppDynamics. All rights Reserved.