Skip to main content

Keeping Digital Business Running

Network Performance Management for Digital Operations
Jim Frey

The importance of digital business operations is now a given, and for good reason. Recently, Pandora announced that it was launching a subscription service and lowering monthly fees, which means that the already huge percentage of its revenues driven by advertising is going to have to increase in order to maintain the top line. It goes without saying that streaming music, like many other ad-driven business models, relies critically on user experience, and user experience relies critically on network performance. So much so that streaming media, gaming and many other such digital service providers have built private CDNs to guarantee that app and ad bits make it to user eyes and ears in a very timely and reliable fashion.

Network performance monitoring (NPM) has been around a long time. Unlike APM, NPM is still in the process of catching up to cloud realities. In May of this year, Gartner analyst Sanjit Ganguli published a research note entitled Network Performance Monitoring Tools Leave Gaps in Cloud Monitoring. It's a fairly biting critique of the NPM space that says, essentially, that the vast majority of current NPM approaches were largely built for a pre-cloud era, and are unable to adapt because of the new complexities brought by decentralization and full stack virtualization. As a result, network managers are left in the lurch when trying to adapt to the realities of digital operations.

NPM had its origins in open-source manual tools such as MRTG, Nagios, and Wireshark, which are still widely available and useful. However, on a commercial basis, traditional NPM approaches came about during the rise of centralized, private enterprise data centers connected by networks that were built to reach campuses and branch offices across an outsourced, yet essentially private IP/MPLS WAN. Applications of this era were developed in a relatively monolithic fashion. This overall architecture meant that there a few, well defined traffic aggregation points, such as the juncture between LAN and WAN at major datacenters and campuses. Enterprise switches and routers deployed in these environments offered span ports, and thus a generation of NPM packet capture (PCAP) appliances were born that could attach to these span ports directly or via a convenient tap or packet broker device. Appliances weren't the exclusive domain of NPM offerings – they were used for many network management and security products and still are – but the majority of packet-centric NPM solutions leverage appliances to achieve scale and PCAP storage objectives.

A funny thing happened though – the cloud. The rise of IaaS, PaaS, and SaaS meant that there was a new breed of alternative for just about every IT infrastructure and application component. Applications becoming more and more distributed and, increasingly, components started living not just in separate containers, VMs and infrastructure clusters, but in separate datacenters, spread out across networks and the Internet. This cloud way of developing, distributing, hosting and communicating established a dramatically altered set of network traffic patterns.

Unfortunately, NPM appliances aren't nearly as helpful in this new reality. In many clouds you don't have a network interface to tap into for sniffing or capturing packets. The proliferation of application components multiplies the communication endpoints.

In addition, digital business means that users aren't necessarily reached across a private WAN, but rather across the Internet.

Finally, appliances are bedeviled by limited storage and compute power, so they can't offer very much depth of analysis without extreme cost impact. With digital business and DevOps practices being so data-driven, being limited to summary reports and a small window of details isn't acceptable anymore, especially when scale-out computing and storage is so readily available.

This change in how the network and Internet interacts with and influences application performance requires a new approach to NPM. NPM for the digital operations era needs to offer a level of flexibility in deployment and cost-effectiveness to allow for broad, comprehensive instrumentation to collect network performance metric data. In addition, the volume of network performance data ingest, depth of storage, and analytical sophistication needs to scale based on today's cloud economics. Fortunately, there are plenty of technology options available to build these capabilities. So while Gartner has rightly identified a gap in NPM, the good news is that the gap can be readily filled.

Hot Topics

The Latest

Edge AI is strategically embedded in core IT and infrastructure spending across industries, according to the 2026 Edge AI Survey from ZEDEDA. The research shows that 83% of C-suite and IT executive respondents say edge AI is important to their core business strategy ...

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...

40% of organizations deploying AI will implement dedicated AI observability tools by 2028 to monitor model performance, bias and outputs, according to Gartner ...

Until AI-powered engineering tools have live visibility of how code behaves at runtime, they cannot be trusted to autonomously ensure reliable systems, according to the State of AI-Powered Engineering Report 2026 report from Lightrun. The report reveals that a major volume of manual work is required when AI-generated code is deployed: 43% of AI-generated code requires manual debugging in production, even after passing QA or staging tests. Furthermore, an average of three manual redeploy cycles are required to verify a single AI-suggested code fix in production ...

Many organizations describe AI as strategic, but they do not manage it strategically. When AI plans are disconnected from strategy, detached from organizational learning, and protected from serious assumptions testing, the problem is no longer technical immaturity; it is a failure of management discipline ... Executives too often tell organizations to "use AI" before they define what AI is supposed to change. The problem deepens in organizations where strategy isn't well articulated in the first place ...

Across the enterprise technology landscape, a quiet crisis is playing out. Organizations have run hundreds, sometimes thousands, of generative AI pilots. Leadership has celebrated the proof of concept (POCs) ... Industry experience points to a sobering reality: only 5-10% of AI POCs that progress to the pilot stage successfully reach scaled production. The remaining 90% fail because the enterprise environment around them was never ready to absorb them, not the AI models ...

Keeping Digital Business Running

Network Performance Management for Digital Operations
Jim Frey

The importance of digital business operations is now a given, and for good reason. Recently, Pandora announced that it was launching a subscription service and lowering monthly fees, which means that the already huge percentage of its revenues driven by advertising is going to have to increase in order to maintain the top line. It goes without saying that streaming music, like many other ad-driven business models, relies critically on user experience, and user experience relies critically on network performance. So much so that streaming media, gaming and many other such digital service providers have built private CDNs to guarantee that app and ad bits make it to user eyes and ears in a very timely and reliable fashion.

Network performance monitoring (NPM) has been around a long time. Unlike APM, NPM is still in the process of catching up to cloud realities. In May of this year, Gartner analyst Sanjit Ganguli published a research note entitled Network Performance Monitoring Tools Leave Gaps in Cloud Monitoring. It's a fairly biting critique of the NPM space that says, essentially, that the vast majority of current NPM approaches were largely built for a pre-cloud era, and are unable to adapt because of the new complexities brought by decentralization and full stack virtualization. As a result, network managers are left in the lurch when trying to adapt to the realities of digital operations.

NPM had its origins in open-source manual tools such as MRTG, Nagios, and Wireshark, which are still widely available and useful. However, on a commercial basis, traditional NPM approaches came about during the rise of centralized, private enterprise data centers connected by networks that were built to reach campuses and branch offices across an outsourced, yet essentially private IP/MPLS WAN. Applications of this era were developed in a relatively monolithic fashion. This overall architecture meant that there a few, well defined traffic aggregation points, such as the juncture between LAN and WAN at major datacenters and campuses. Enterprise switches and routers deployed in these environments offered span ports, and thus a generation of NPM packet capture (PCAP) appliances were born that could attach to these span ports directly or via a convenient tap or packet broker device. Appliances weren't the exclusive domain of NPM offerings – they were used for many network management and security products and still are – but the majority of packet-centric NPM solutions leverage appliances to achieve scale and PCAP storage objectives.

A funny thing happened though – the cloud. The rise of IaaS, PaaS, and SaaS meant that there was a new breed of alternative for just about every IT infrastructure and application component. Applications becoming more and more distributed and, increasingly, components started living not just in separate containers, VMs and infrastructure clusters, but in separate datacenters, spread out across networks and the Internet. This cloud way of developing, distributing, hosting and communicating established a dramatically altered set of network traffic patterns.

Unfortunately, NPM appliances aren't nearly as helpful in this new reality. In many clouds you don't have a network interface to tap into for sniffing or capturing packets. The proliferation of application components multiplies the communication endpoints.

In addition, digital business means that users aren't necessarily reached across a private WAN, but rather across the Internet.

Finally, appliances are bedeviled by limited storage and compute power, so they can't offer very much depth of analysis without extreme cost impact. With digital business and DevOps practices being so data-driven, being limited to summary reports and a small window of details isn't acceptable anymore, especially when scale-out computing and storage is so readily available.

This change in how the network and Internet interacts with and influences application performance requires a new approach to NPM. NPM for the digital operations era needs to offer a level of flexibility in deployment and cost-effectiveness to allow for broad, comprehensive instrumentation to collect network performance metric data. In addition, the volume of network performance data ingest, depth of storage, and analytical sophistication needs to scale based on today's cloud economics. Fortunately, there are plenty of technology options available to build these capabilities. So while Gartner has rightly identified a gap in NPM, the good news is that the gap can be readily filled.

Hot Topics

The Latest

Edge AI is strategically embedded in core IT and infrastructure spending across industries, according to the 2026 Edge AI Survey from ZEDEDA. The research shows that 83% of C-suite and IT executive respondents say edge AI is important to their core business strategy ...

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...

40% of organizations deploying AI will implement dedicated AI observability tools by 2028 to monitor model performance, bias and outputs, according to Gartner ...

Until AI-powered engineering tools have live visibility of how code behaves at runtime, they cannot be trusted to autonomously ensure reliable systems, according to the State of AI-Powered Engineering Report 2026 report from Lightrun. The report reveals that a major volume of manual work is required when AI-generated code is deployed: 43% of AI-generated code requires manual debugging in production, even after passing QA or staging tests. Furthermore, an average of three manual redeploy cycles are required to verify a single AI-suggested code fix in production ...

Many organizations describe AI as strategic, but they do not manage it strategically. When AI plans are disconnected from strategy, detached from organizational learning, and protected from serious assumptions testing, the problem is no longer technical immaturity; it is a failure of management discipline ... Executives too often tell organizations to "use AI" before they define what AI is supposed to change. The problem deepens in organizations where strategy isn't well articulated in the first place ...

Across the enterprise technology landscape, a quiet crisis is playing out. Organizations have run hundreds, sometimes thousands, of generative AI pilots. Leadership has celebrated the proof of concept (POCs) ... Industry experience points to a sobering reality: only 5-10% of AI POCs that progress to the pilot stage successfully reach scaled production. The remaining 90% fail because the enterprise environment around them was never ready to absorb them, not the AI models ...