Edge computing has been “the next big thing” for about five years now. According to vendors, everything should be moving to the edge. Latency is terrible. Bandwidth costs are unsustainable. Data sovereignty requires local processing. The future is distributed.

Then you look at what most organizations actually need, and edge computing solves problems that don’t exist while creating operational complexity that definitely does.

I’m not saying edge computing is useless. There are genuine use cases where processing data close to where it’s generated makes sense. But they’re more specific than the marketing suggests, and most enterprises don’t have them.

What Edge Computing Actually Means

The term “edge computing” gets used for everything from CDN caching to industrial IoT to retail point-of-sale systems. That’s too broad to be useful.

For this discussion, I’m talking about computational workloads that run outside centralized data centers, closer to data sources or end users. This might be on-premises hardware in retail locations, gateway devices in factories, or compute resources distributed across geographic regions.

The distinguishing characteristic is that you’re giving up some centralized control in exchange for some benefit. Lower latency, reduced bandwidth usage, better reliability, or data sovereignty. If you’re not getting one of those benefits, you’re probably just making your infrastructure more complicated.

The Latency Argument

Latency is the most common justification for edge computing. If processing happens closer to users or devices, round-trip time is lower. For some applications, this matters.

Gaming and real-time interaction genuinely need low latency. If you’re building a multiplayer game or video conferencing system, every 50ms of latency is noticeable. Edge computing that places servers geographically closer to users can reduce latency from 150ms to 20ms. That’s a meaningful improvement.

But for most business applications, this doesn’t matter. Is your CRM faster if the servers are in Sydney versus Singapore? Probably not noticeably. The database query time and application logic time dwarf network latency. Adding 50ms of network round-trip is lost in the noise.

We spent time evaluating edge deployment for one of our customer-facing applications. The theory was that response times would improve if we deployed regionally. After testing, the improvement was about 30ms on average. Users wouldn’t notice. We didn’t deploy it.

The latency benefit is real for specific use cases: gaming, video processing, industrial control systems, autonomous vehicles. For business applications serving humans through web browsers, it usually doesn’t matter.

The Bandwidth Argument

Bandwidth costs money and has limits. If you’re generating large amounts of data and sending it to centralized cloud services for processing, bandwidth can be expensive. Processing data locally and only sending results or summaries reduces bandwidth usage.

This makes sense for video analytics, industrial IoT, and retail with high-resolution security cameras. A retail store with 50 cameras generating 4K video feeds produces huge data volumes. Sending all that video to the cloud for processing is expensive and slow. Running computer vision locally and only sending alerts when something interesting happens is much more practical.

But most business data isn’t video. It’s transactional data, user events, logs, and metrics. The volume is manageable. We collect hundreds of gigabytes of log data daily across our infrastructure and send it to centralized log aggregation. The bandwidth cost is maybe $500 monthly. Not worth optimizing with edge infrastructure.

The bandwidth argument is compelling in specific scenarios but doesn’t apply to most enterprise workloads.

The Reliability Argument

If your application depends on connectivity to central services, network issues break everything. Deploying processing at the edge means local functionality continues even if central connectivity is disrupted.

This is critical for some applications. Point-of-sale systems need to process transactions even if the internet connection goes down. You can’t tell customers “sorry, can’t check you out, our cloud is unreachable.” Local processing with eventual synchronization to central systems is necessary.

Industrial control systems are similar. A factory can’t stop operating because of network issues. Local control systems need autonomy with central coordination when connectivity is available.

But for most SaaS applications, this isn’t a concern. If your application requires internet connectivity anyway, processing locally versus centrally doesn’t change reliability. If the internet is down, the application doesn’t work regardless of where processing happens.

The Data Sovereignty Argument

Some jurisdictions require that data doesn’t leave geographic boundaries. GDPR has restrictions on transferring data outside the EU. China requires data about Chinese citizens to stay in China. Various industries have similar requirements.

Edge computing can help with this by processing data locally within required jurisdictions and only transferring aggregated or anonymized results. This is a real benefit when regulatory requirements create constraints.

But you need to be careful about what “data sovereignty” actually requires. Often it’s about where data is stored, not where it’s processed. Cloud providers now have data centers in most major jurisdictions. Storing data in AWS’s Sydney region addresses Australian data sovereignty concerns without requiring edge infrastructure.

Real edge computing for data sovereignty is needed when regulations prohibit data from leaving a specific site, not just a country. Healthcare and defense have these requirements sometimes. Most businesses don’t.

Where We Actually Use Edge Computing

We have edge infrastructure in exactly one context: IoT gateways for industrial customers. These customers have sensor networks generating time-series data in factories. The gateways pre-process data, filter noise, detect anomalies, and send aggregated results to our central platform.

This works because the use case fits multiple criteria. Bandwidth matters (sending raw sensor data from thousands of devices would be expensive). Latency matters (real-time anomaly detection needs quick response). Reliability matters (local processing continues if connectivity drops).

For everything else, we run centrally in AWS. It’s simpler, easier to monitor, easier to update, and easier to scale. The operational complexity of distributed edge infrastructure isn’t worth it unless you have compelling reasons.

The Operational Complexity Problem

Running infrastructure at the edge means you’re responsible for hardware in locations you don’t control. Someone needs to provision devices, manage updates, monitor health, and deal with hardware failures.

This is manageable if you have a few locations. It becomes a nightmare with dozens or hundreds of edge sites. You need remote management capabilities, monitoring systems that work despite unreliable connectivity, and processes for dealing with hardware issues.

Cloud providers are trying to make this easier with managed edge services. AWS has Outposts and Wavelength. Azure has Edge Zones. Google has Distributed Cloud. These help, but they still require more operational overhead than centralized cloud infrastructure.

Unless you have a clear benefit that justifies this complexity, stay centralized.

When to Actually Consider Edge Computing

You should evaluate edge computing if you have one or more of these situations:

Real-time requirements where every millisecond matters and processing needs to happen within single-digit millisecond timeframes. This is rare outside of gaming and industrial control.

Massive data generation where bandwidth costs of sending everything centrally would be prohibitive. Video analytics and high-frequency IoT are the main examples.

Regulatory requirements that mandate data processing within specific geographic boundaries or on-premises. Make sure you understand what’s actually required, not just what vendors claim you need.

Reliability requirements where local functionality must continue during network outages. Point-of-sale and industrial control systems fall into this category.

If you don’t have at least one of these requirements, edge computing is probably adding complexity without corresponding value.

The Marketing vs Reality Gap

Edge computing vendors would have you believe that the future is massively distributed, with processing happening everywhere except centralized data centers. This serves their interest in selling edge hardware and software, but it doesn’t match what most organizations actually need.

Centralized cloud infrastructure is easier to manage, easier to monitor, easier to secure, and easier to scale. The economies of scale at hyperscale cloud providers mean better price-performance than you can achieve with distributed edge infrastructure.

Edge computing has genuine use cases, but they’re more specific than the hype suggests. Don’t adopt edge architecture because it’s trendy. Adopt it because you have a clear problem that edge computing solves better than alternatives.

Most organizations will run primarily in centralized cloud environments for the foreseeable future, with edge computing used selectively for specific workloads where it provides clear benefits. That’s the practical reality behind the marketing hype.