Skip to main content

Not All Networks Are Built for the Edge

Julio Petrovitch
NetAlly

From smart factories and autonomous vehicles to real-time analytics and intelligent building systems, the demand for instant, local data processing is exploding. To meet these needs, organizations are leaning into edge computing. The promise? Faster performance, reduced latency and less strain on centralized infrastructure.

But there's a catch: Not every network is ready to support edge deployments. The shift from cloud to edge isn't a silver bullet … it comes with its own set of performance, connectivity and security challenges that can derail return on investment if IT teams aren't prepared. Before rushing into edge, it's worth asking: Is your network actually built for it?

Recent research from IDC shows that global spending on edge computing is expected to reach around $261 billion in 2025. Despite its advantages, edge computing introduces a new layer of complexity. Moving workloads closer to the source doesn't inherently solve latency. Local bottlenecks like Wi-Fi congestion, inefficient routing, and oversubscribed nodes can impact performance. For example, a retail store using edge-based video analytics might run into delays, not because the analytics system is slow, but because the Wi-Fi is overloaded. With numerous devices fighting for bandwidth or a single access point stretched too thin, performance can take a hit. Measuring round-trip latency at the point of deployment is essential to validate that the edge network is delivering on its promise.

Coverage gaps and internal bandwidth limitations also pose risks. Many edge and IoT devices are deployed in low-signal environments (ceilings, walls, utility spaces) where connectivity can be unreliable without precise, location-based testing.

Meanwhile, increased east-west traffic from localized processing can strain internal links that weren't designed for high-volume lateral communication. Imagine a building automation system where sensors are installed behind ceiling tiles or inside utility closets. On paper, the network coverage might look sufficient — but in practice, those materials can block or degrade the signal. Without testing connectivity at the exact device location, these sensors could drop offline or send delayed data, undermining the reliability of the entire system.

The surge in east-west traffic at the edge doesn't just strain network capacity; it also complicates security monitoring. Traditional perimeter defenses and cloud-based firewalls may not see lateral communications between devices. Without continuous visibility and anomaly detection, malicious activity can blend in with normal machine-to-machine chatter.

Beyond performance and reliability, security must be front and center. Every new sensor, kiosk, or edge server adds another potential entry point for attackers. Unlike data centers and company HQs with hardened perimeters, edge devices are often deployed in uncontrolled environments like retail floors, factory lines, or remote offices where they may be more vulnerable to physical tampering. Centralized monitoring technologies like Endpoint Detection and Response are less effective at the network edge, so the risk of rogue access points or unsecured ports is higher. Malicious activity or unusual network behavior will be harder to detect. Finally, edge devices themselves often use outdated operating systems and basic software with many security flaws.

Maximizing the value of edge computing starts with proactive planning and rigorous validation. That begins by measuring latency before and after deployment — not just at the network level, but for each specific application and service. Round-trip testing and packet analysis can confirm whether devices are reliably connecting with intended endpoints and performing within acceptable thresholds.

General proximity is not enough when it comes to wireless coverage, it must be assessed at the physical device location. Research from 2024 confirms that signal strength can deteriorate dramatically with just a few meters of distance or light obstruction. The study, measuring Wi-Fi signal quality from 1 meter to 15 meters from a router, found a significant drop in signal strength and data speed as distance increased, with performance further degraded by walls, furniture, and other obstructions — as would be expected. For instance, imagine a smart sensor mounted in a warehouse ceiling. On a map, it's well within range of the nearest access point, but thick steel rafters and high shelving panels obstruct the Wi-Fi path. At that exact location, signal strength can fall below usable thresholds, causing intermittent dropouts or delayed transmissions that wouldn't be caught unless measured in proximity to the sensor itself.

It's also important that signal quality and load testing simulate real-world conditions to ensure infrastructure can handle demand as deployments scale. With east-west (internal, device-to-device) traffic increasing, IT teams should test throughput across switch-to-switch and access-layer connections. At the same time, north-south (external, device-to-cloud) traffic should be validated to confirm critical applications can reliably reach data center and cloud services. Together, these tests ensure both internal and external paths can support elevated loads without introducing bottlenecks.

Edge computing can unlock significant performance gains, reduce latency, and shift compute load from centralized infrastructure — but only when the underlying network is both performance-ready and secure. Success depends on more than shifting workloads closer to devices. It requires deliberate testing, full visibility, and cross-functional coordination. By validating latency, assessing wireless coverage, stress-testing both east-west and north-south links, and securing every endpoint, IT leaders can avoid common pitfalls and deliver the reliability, responsiveness, and protection their users expect.

Julio Petrovitch is a Product Manager at NetAlly

The Latest

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 ...

Today's modern systems are not what they once were. Organizations now rely on distributed systems, event-driven workflows, hybrid and multi-cloud environments and continuous delivery pipelines. While each adds flexibility, it also introduces new, often invisible failures. Development speed is no longer the primary bottleneck of innovation. Reliability is ...

Seeing is believing, or in this case, seeing is understanding, according to New Relic's 2025 Observability Forecast for Retail and eCommerce report. Retailers who want to provide exceptional customer experiences while improving IT operations efficiency are leaning on observability ... Here are five key takeaways from the report ...

Not All Networks Are Built for the Edge

Julio Petrovitch
NetAlly

From smart factories and autonomous vehicles to real-time analytics and intelligent building systems, the demand for instant, local data processing is exploding. To meet these needs, organizations are leaning into edge computing. The promise? Faster performance, reduced latency and less strain on centralized infrastructure.

But there's a catch: Not every network is ready to support edge deployments. The shift from cloud to edge isn't a silver bullet … it comes with its own set of performance, connectivity and security challenges that can derail return on investment if IT teams aren't prepared. Before rushing into edge, it's worth asking: Is your network actually built for it?

Recent research from IDC shows that global spending on edge computing is expected to reach around $261 billion in 2025. Despite its advantages, edge computing introduces a new layer of complexity. Moving workloads closer to the source doesn't inherently solve latency. Local bottlenecks like Wi-Fi congestion, inefficient routing, and oversubscribed nodes can impact performance. For example, a retail store using edge-based video analytics might run into delays, not because the analytics system is slow, but because the Wi-Fi is overloaded. With numerous devices fighting for bandwidth or a single access point stretched too thin, performance can take a hit. Measuring round-trip latency at the point of deployment is essential to validate that the edge network is delivering on its promise.

Coverage gaps and internal bandwidth limitations also pose risks. Many edge and IoT devices are deployed in low-signal environments (ceilings, walls, utility spaces) where connectivity can be unreliable without precise, location-based testing.

Meanwhile, increased east-west traffic from localized processing can strain internal links that weren't designed for high-volume lateral communication. Imagine a building automation system where sensors are installed behind ceiling tiles or inside utility closets. On paper, the network coverage might look sufficient — but in practice, those materials can block or degrade the signal. Without testing connectivity at the exact device location, these sensors could drop offline or send delayed data, undermining the reliability of the entire system.

The surge in east-west traffic at the edge doesn't just strain network capacity; it also complicates security monitoring. Traditional perimeter defenses and cloud-based firewalls may not see lateral communications between devices. Without continuous visibility and anomaly detection, malicious activity can blend in with normal machine-to-machine chatter.

Beyond performance and reliability, security must be front and center. Every new sensor, kiosk, or edge server adds another potential entry point for attackers. Unlike data centers and company HQs with hardened perimeters, edge devices are often deployed in uncontrolled environments like retail floors, factory lines, or remote offices where they may be more vulnerable to physical tampering. Centralized monitoring technologies like Endpoint Detection and Response are less effective at the network edge, so the risk of rogue access points or unsecured ports is higher. Malicious activity or unusual network behavior will be harder to detect. Finally, edge devices themselves often use outdated operating systems and basic software with many security flaws.

Maximizing the value of edge computing starts with proactive planning and rigorous validation. That begins by measuring latency before and after deployment — not just at the network level, but for each specific application and service. Round-trip testing and packet analysis can confirm whether devices are reliably connecting with intended endpoints and performing within acceptable thresholds.

General proximity is not enough when it comes to wireless coverage, it must be assessed at the physical device location. Research from 2024 confirms that signal strength can deteriorate dramatically with just a few meters of distance or light obstruction. The study, measuring Wi-Fi signal quality from 1 meter to 15 meters from a router, found a significant drop in signal strength and data speed as distance increased, with performance further degraded by walls, furniture, and other obstructions — as would be expected. For instance, imagine a smart sensor mounted in a warehouse ceiling. On a map, it's well within range of the nearest access point, but thick steel rafters and high shelving panels obstruct the Wi-Fi path. At that exact location, signal strength can fall below usable thresholds, causing intermittent dropouts or delayed transmissions that wouldn't be caught unless measured in proximity to the sensor itself.

It's also important that signal quality and load testing simulate real-world conditions to ensure infrastructure can handle demand as deployments scale. With east-west (internal, device-to-device) traffic increasing, IT teams should test throughput across switch-to-switch and access-layer connections. At the same time, north-south (external, device-to-cloud) traffic should be validated to confirm critical applications can reliably reach data center and cloud services. Together, these tests ensure both internal and external paths can support elevated loads without introducing bottlenecks.

Edge computing can unlock significant performance gains, reduce latency, and shift compute load from centralized infrastructure — but only when the underlying network is both performance-ready and secure. Success depends on more than shifting workloads closer to devices. It requires deliberate testing, full visibility, and cross-functional coordination. By validating latency, assessing wireless coverage, stress-testing both east-west and north-south links, and securing every endpoint, IT leaders can avoid common pitfalls and deliver the reliability, responsiveness, and protection their users expect.

Julio Petrovitch is a Product Manager at NetAlly

The Latest

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 ...

Today's modern systems are not what they once were. Organizations now rely on distributed systems, event-driven workflows, hybrid and multi-cloud environments and continuous delivery pipelines. While each adds flexibility, it also introduces new, often invisible failures. Development speed is no longer the primary bottleneck of innovation. Reliability is ...

Seeing is believing, or in this case, seeing is understanding, according to New Relic's 2025 Observability Forecast for Retail and eCommerce report. Retailers who want to provide exceptional customer experiences while improving IT operations efficiency are leaning on observability ... Here are five key takeaways from the report ...