APM Insights: Beyond the Acronym

Application Performance Management

Subscribe to Application Performance Management: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Application Performance Management: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


APM Authors: Mehdi Daoudi, Derek Weeks, XebiaLabs Blog, Elizabeth White, SmartBear Blog

Related Topics: ERP Journal on Ulitzer, Development Testing, Application Performance Management (APM), DevOps Journal

Article

Can Wire Data Be #APM? | @DevOpsSummit #DevOps #AI #ML #Monitoring

In general terms APM is simply 'the monitoring and management of the performance and availability of software applications'

Can Wire Data Be APM?

I recently read something – a blog, a tweet, a LinkedIn article perhaps – describing the use of wire data to analyze application performance. I remember that the author’s use of the term “APM” in this context caused one reader to comment, complaining that “you can’t call wire data APM.” This was around the same time I referred casually to Dynatrace’s wire data offering (Data Center Real User Monitoring, or DC RUM) as both “APM for IT Operations” and “probe-based APM.” So that complaint has stuck with me, prompting me to ask – and offer an answer to – the question.

It depends, of course, on answers to related questions. How do you define APM? What role does APM play in your organization? What APM insights can wire data provide? Let’s take a brief look at each of these.

What is APM to you?
In very general terms (Wikipedia is great for this), APM is simply “the monitoring and management of the performance and availability of software applications.” This is accomplished by measuring user response times, transaction volume (load), and resource consumption, with correlation to help identify system bottlenecks. But of course that description is too vague to be of much practical use. For more depth and breadth, we can turn to Gartner’s recent update to its 2010 definition of APM. Collapsed from the original five, Gartner now identifies three functional dimensions. In brief, these are:

  1. Digital experience monitoring – understanding the availability and performance of real and synthetic users.
  2. Application discovery, tracing and diagnostics – discovering application services, tracing transactions through the infrastructure, and deep insight into code execution. (This new dimension used to be three separate but interlinked dimensions.)
  3. Application analytics – automating the isolation and analysis of performance bottlenecks and fault domains.

Beyond the helpful simplification of the dimensions, there’s another interesting change to Gartner’s definition; it now explicitly calls out requirements for specific technology platforms. Included are web and mobile, HTTP, Java and .NET; by omission, all others are excluded.

“Traditional” APM architectures
To some degree, this narrowing (or perhaps clarification) of APM’s scope to focus to web stacks reflects a general market reality, if not a vendor-driven market definition; every APM vendor supports these stacks, and most don’t venture far beyond. The standardization and openness of these platforms encouraged development of compelling solutions to meet the monitoring needs of modern customer-facing web applications. Whether an offering’s pedigree can be traced to development tools or production monitoring, there’s no doubt that the performance visibility and diagnostic insights have helped many IT organizations modernize their operations, enable DevOps initiatives, and accelerate the shift from providing infrastructure and capacity to delivering business-oriented application services.

At least for mission-critical web apps.

Mission critical? Or vendor critical?
There’s a disconnect, however, that one of my colleagues helpfully calls “the myth of mission critical.” I see that myth as having two facets.

First, at a high level, it implies that some apps are not critical, and therefore don’t warrant monitoring. Maybe it’s a matter of degree – critical vs. important. But if an application isn’t at least important, why do you still have it? And if it is important, shouldn’t you be monitoring it?

The second facet is vendor-driven; APM vendors have steered the mission-critical discussion to web apps, the “apps of engagement” that are revenue-producing for many businesses. Distilling the messaging, one might conclude that “web apps are mission-critical; non-web apps are not.” This sounds like a spin on Maslow’s law of the hammer, illustrated nicely by Grace Witherell: “When all you have is a hammer, only nails are problems.”

I’d venture to say that your Oracle EBS and Forms-based apps, your SAP ERP applications, your Epic EHR and other custom thick-client applications that might be delivered via Citrix, all running core parts of your business – these and many others like them are probably critical as well.

But these “other” (i.e., non-web) apps run on a diverse set of often proprietary or closed platforms, without the instrumentation interfaces that have facilitated agent-based APM solutions for Java and .NET.

APM for IT operations
APM solutions often – always, maybe – support many user roles. Gartner’s recent Magic Quadrant for APM suggests that in a few years, only 30% of APM buyers will be in IT operations, down from 60% today; most of the other buyers will be application support and development. This doesn’t reflect a loss of interest on the part of IT operations, but rather an expanding audience of stakeholders – some of whom will have diverging interests.

One dominant example of these different interests is reflected in the need for code-level insight, a component of the second of the three APM dimensions. Application development and support teams likely need this, at least for applications built or customized and maintained in-house. But for IT operations teams, code-level insight may be less of a priority; common operational goals such as meeting service quality SLAs, reducing MTTR, and controlling costs can be easily accomplished by other APM capabilities. And the lack of code-level monitoring doesn’t preclude effective DevOps collaboration; inter-tier transaction monitoring and parameter capture help fill the gap.

Wire data
Wire data simply refers to an approach to gathering information – about performance, availability, usage, security, users, applications, networks, and much more. The type of information and the resulting value depends on the analytics applied to the data. Unlike agent technology, however, wire data is platform agnostic, unconcerned with the source application architecture. Instead, wire data relies on protocol decodes to be relevant. First tier examples include HTTP, SAPGUI, Oracle Forms, Epic, and Citrix ICA, while back end examples include SOAP, various forms of SQL, WebSphere MQ, CORBA, and more.

Analytics transforms this interpreted wire data into useful insights, and at Dynatrace, we’ve built a wire data analytics platform (DC RUM) that focuses on delivering application and user performance insights – in fact, mirroring many of the core capabilities defined by Gartner’s APM dimensions. These include:

  • EUE monitoring to help prioritize IT actions based on business impact
  • Automatic discovery to maintain visibility in increasingly dynamic environments
  • Automatic identification of users, transaction names and parameters
  • Robust analytics to automatically isolate fault domains and break out response time components
  • Detailed analysis of network performance and its impact on user experience

For an expansion of these wire data capabilities, you can read my blog “Where APM Agents Fear to Tread.”

In fact, the primary limitation of a wire data approach to APM might simply be the lack of code-level insights; in its place, however, wire data can offer enhanced network infrastructure visibility as well as enterprise-wide application coverage; for IT operations teams, that’s often a reasonable – if not desirable – tradeoff.

A positive-sum game
In the end, however, this isn’t a zero-sum game. Real benefits can be achieved through multiple perspectives of performance. An agent’s inside-out perspective – with deep code-level insights – gains new insights with the outside-in perspective of wire data, with its greater network awareness. The point is not to argue the merits of a specific collection technology, but to offer a multi-faceted solution that meets the needs of multiple stakeholders by covering your entire application portfolio.

At Dynatrace, we’re redefining monitoring to mean every user, every app, everywhere. This doesn’t mean separate products for different environments; it means a unified and modular AI-driven solution that offers comprehensive coverage for enterprise, web and newstack environments.

So, can wire data be APM? Some APM vendors want to argue that it can’t, but it might be that they’ve got only hammers to sell.

The post Can wire data be APM? appeared first on Dynatrace blog – monitoring redefined.

More Stories By Gary Kaiser

Gary Kaiser is a Subject Matter Expert in Network Performance Analytics at Dynatrace, responsible for DC RUM’s technical marketing programs. He is a co-inventor of multiple performance analysis features, and continues to champion the value of network performance analytics. He is the author of Network Application Performance Analysis (WalrusInk, 2014).

More Stories By Dynatrace Blog

Building a revolutionary approach to software performance monitoring takes an extraordinary team. With decades of combined experience and an impressive history of disruptive innovation, that’s exactly what we ruxit has.

Get to know ruxit, and get to know the future of data analytics.