Edge computing moves data processing away from remote data centres and towards the place where data is generated: the factory floor, the vehicle, the 5G antenna or the device itself. The motivation is not ideological — it is physical. The speed of light imposes a hard limit: every 100 kilometres of fibre adds roughly half a millisecond of latency from propagation alone, before accounting for the processing time of intermediate equipment. For industrial control, assisted driving or augmented-reality applications, that round-trip to a data centre hundreds of kilometres away is simply incompatible with the response time the task demands.
Why latency matters: the millisecond budget
It helps to reason in terms of a "latency budget." A robotic arm that must stop when an obstacle appears, a vision system that classifies parts on a conveyor belt, or an augmented-reality experience that must keep content anchored to the real world all have a few tens of milliseconds for the entire cycle: capture, transmit, process and act. If the network consumes most of that budget, there is no margin left for computation. Edge computing solves the equation by bringing the compute closer: the response does not have to cross the country.
It is worth distinguishing three layers. Cloud computing centralises computation in large regional facilities and prioritises capacity and cost per operation. The edge distributes computation close to the source of the data and prioritises latency and resilience against connectivity failures. Between the two sits fog computing, an intermediate layer of gateways and regional micro-data centres that aggregate and pre-process before uploading only what is truly necessary to the cloud.
The role of 5G and the access network
5G is not merely "faster mobile." Its URLLC (Ultra-Reliable Low-Latency Communications) variant is designed for user-plane latencies of around 1 millisecond and reliability of 99.999%. Combined with MEC (Multi-access Edge Computing), the operator deploys computing capacity at the base station itself or at the edge of the mobile network, so that the application runs within one or two hops of the device. Network slicing additionally allows a logical slice of the network to be reserved with quality-of-service guarantees for critical cases, keeping it separate from general consumer traffic.
The MEC standard is defined by ETSI, which specifies how applications can be hosted at the operator's network edge and consume platform services such as location or radio information. This opens a deployment model in which business logic lives at the operator level, not on the device or in a remote cloud region. For a connected factory, port or stadium, that intermediate layer resolves the tension between having compute nearby and not having to manage servers at every location.
Practical case: machine vision on the production line
A recurrent example illustrates the value of edge computing. An industrial camera inspects parts on a high-speed conveyor belt and a vision model decides whether each part is conformant. If inference were to run in the cloud, the video would have to be uploaded, processed, and the decision returned before an actuator rejects the defective part — the latency budget does not allow it, and uploading a continuous video stream is also prohibitively expensive in terms of bandwidth. The edge architecture solves the equation by running the inference model on a local node with an accelerator, so the decision is made in milliseconds next to the belt. The cloud is reserved for periodically retraining the model using the difficult cases flagged by the edge and for distributing the new version to the entire camera fleet. This is the canonical pattern: inference at the edge, training in the cloud.
Industrial IoT: from raw data to local decisions
In an industrial IoT environment, a single production line can generate gigabytes per hour of sensor telemetry. Sending all of that to the cloud is expensive and unnecessary. The standard pattern is to process at the edge: filter, aggregate, detect anomalies and act immediately, uploading only summaries and relevant events to the cloud for historical analysis and model training. This architecture delivers four concrete advantages: near-real-time response, reduced bandwidth consumption, operational continuity if the cloud link goes down, and improved privacy compliance by keeping sensitive data within the perimeter.
| Criterion | Centralised cloud | Edge computing |
|---|---|---|
| Typical latency | Tens to hundreds of ms | Single-digit ms or less |
| Bandwidth to the core | High (uploads everything) | Low (uploads summaries) |
| Resilience on network outage | Service interrupted | Local operation continues |
| Fleet management cost | Low (centralised) | High (many distributed nodes) |
| Compute capacity per node | Practically unlimited | Limited by local hardware |
How to implement an edge architecture
An orderly implementation follows several steps. First, characterise the workloads: identify what needs an immediate response (stays at the edge) and what can tolerate latency (goes to the cloud). Second, choose the node hardware according to the environment (industrial-hardened, inference accelerators for vision, power consumption constraints). Third, define the orchestration layer: lightweight Kubernetes distributions such as K3s or KubeEdge allow containers to be deployed and updated across hundreds of remote nodes in a consistent manner. Fourth, design the data synchronisation strategy with tolerance for disconnections (store and forward). Fifth, harden security: each node is an attack surface that is physically exposed, so secure boot, encryption at rest, per-device identity and signed updates are essential. Finally, instrument remote observability to diagnose nodes that cannot be reached in person.
The operational challenge that organisations most underestimate is fleet management at scale. Operating three servers and operating a thousand nodes spread across offices, factories or vehicles are qualitatively different problems. Software updates must be progressive and reversible: a new version is deployed to a subset of nodes, its behaviour is observed, and only then is it extended — with the ability to roll back automatically if a version fails. Each device's identity must be backed by hardware (a TPM module or equivalent) to prevent spoofing. And initial provisioning must be zero-touch: a technician connects the equipment on-site and it registers, receives its configuration and enters service without expert manual intervention. Without these three elements — progressive deployment, hardware-backed identity and automatic provisioning — operating costs grow unsustainably with every node added.
Security deserves specific treatment because the threat model changes. In a data centre, physical access is controlled; at the edge, a node may be in a street lamp, a lorry or an unsupervised warehouse. This means assuming that an adversary may have physical access: disk encryption at rest, secrets that are not stored in cleartext on the device, communications that are always authenticated and encrypted, and network segmentation so that compromising one node does not open the door to the rest of the infrastructure. The IEC 62443 standards for industrial environments and ETSI EN 303 645 for consumer IoT devices provide concrete controls that should be built in from the design stage.
Common mistakes
The most frequent mistake is moving workloads to the edge that do not need to be there, multiplying the operational cost of managing a dispersed fleet without any real latency gain. The second is ignoring lifecycle management: updating the firmware of three servers in a rack is trivial; doing so across a thousand gateways scattered across industrial plants without a robust deployment tool is a guaranteed source of incidents. The third is applying data-centre security thinking, forgetting that an edge node can be physically stolen or tampered with. And the fourth is not designing for network failure: if the node stops operating when its cloud link goes down, the main advantage of edge computing has been wasted.
Frequently asked questions
Does edge computing replace the cloud? No, it complements it. The dominant pattern is hybrid: local decisions at the edge, model training, historical analysis and global orchestration in the cloud.
Do I need 5G to do edge computing? It is not mandatory. Edge computing works over industrial Wi-Fi, Ethernet or private networks. 5G adds mobility and guaranteed latency in scenarios where cabling is not feasible or the device is in motion.
Which security standards apply to IoT devices? IEC 62443 is the reference for security in industrial automation systems, and ETSI EN 303 645 sets cybersecurity requirements for consumer IoT devices. Both are useful frameworks for hardening an edge fleet.
How do I manage hundreds of nodes without staff at each site? With edge-specific container orchestration (K3s, KubeEdge) combined with centralised configuration management and signed updates, so that a single team operates the entire fleet remotely and in an auditable way.
Conclusion
Edge computing is not a trend displacing the cloud — it is the architectural response to a physical constraint: some decisions must be made where the data is born because the travel time to a remote data centre exceeds the latency budget of the task. Successful adoption starts with a business question (what needs an immediate response) rather than with the technology. The real challenge lies not in the node hardware, which grows more capable and affordable every year, but in operating a distributed fleet with discipline: consistent orchestration, signed updates, security for physically exposed devices, and design that is tolerant of network outages. At Summum Sistemas we treat edge computing as a governed extension of the infrastructure, not as islands of unmanaged compute.