The first wave of IoT was built on a simple pattern: sensors send everything to the cloud, and the cloud figures out what to do. It worked for small deployments and slow signals. It stopped working when a factory line wanted a decision in a few milliseconds, when a camera produced more video than the uplink could carry, and when a hospital was told its patient data could not leave the building.
Edge computing is the answer to those limits: run the computation near the source of the data instead of in a distant data center. “Near” can mean on the sensor’s own microcontroller, on a gateway in the same building, or on a server rack at a telecom site a few kilometers away. The common thread is that the work happens before the data crosses the wide-area network, and often instead of crossing it.
This guide explains the forces that push computation to the edge, what an edge deployment actually looks like, the trade-offs it introduces, and how to decide which workloads belong there.
The four reasons to compute at the edge
Latency
A round trip to a cloud region takes tens of milliseconds at best and far longer over cellular or satellite links. A robot arm that must stop when a person steps into its cell, or a grid controller reacting to a frequency deviation, cannot wait. Latency is the most cited reason for edge computing, and the only one that cannot be fixed by paying for more cloud.
Bandwidth
A single camera at modest resolution produces more data in a day than a fleet of temperature sensors does in a year. Sending it all upstream is expensive on cellular, impossible on LPWAN, and wasteful anywhere, since most frames contain nothing interesting. Processing on site and sending only events, summaries or clips cuts bandwidth by orders of magnitude.
Resilience
A building whose lights, locks and climate stop working when the internet link drops is badly designed. Local control loops keep running through outages; the cloud receives the backlog when the link returns. This matters most in industrial settings, where downtime has a direct cost, and in remote sites with unreliable connectivity.
Privacy and sovereignty
Some data should never leave a site: raw video of a hospital ward, audio from a home, production recipes from a factory. Processing it locally and transmitting only derived, anonymized results satisfies both regulation and customer trust. Data sovereignty rules in several jurisdictions make this a hard requirement rather than a preference.
What the edge looks like in practice
Edge is a spectrum, not a single place.
At the thinnest end is the device itself. A vibration sensor that computes a frequency spectrum on its MCU and only reports when a peak moves is doing edge computing. So is a TinyML model that detects a keyword or classifies a gesture on a few hundred kilobytes of RAM. This is edge AI at its most constrained.
One step up is the edge gateway: an industrial PC, a Raspberry Pi-class board, or a purpose-built appliance that aggregates dozens or hundreds of devices over Modbus, OPC UA, BLE or Zigbee, runs protocol translation, local rules, buffering and analytics, and talks to the cloud over MQTT. Most of what people call “the edge” in commercial IoT is this box.
Further up are on-premises edge servers and clusters: a rack in a factory running containers and virtual machines, hosting a local historian, a vision inference service, or a digital twin of the line. And at the far end is the telecom or regional edge, where operators and cloud providers place compute at base stations and metro sites so that a 5G-connected device gets single-digit-millisecond response without the data reaching a central region. Fog computing is an older term for this layered middle ground.
The software model
What makes modern edge computing different from the embedded systems of the past is that it borrows cloud tooling. Workloads are packaged as containers, deployed and updated remotely through a device management plane, configured declaratively, and monitored centrally. The cloud platforms each ship an edge runtime that extends their services to local hardware: the same message routing, the same rule engines, the same model deployment, now running on a box in the building and syncing with the cloud when connected.
The typical data flow is: ingest locally, filter and aggregate at the edge, act locally where a rule or model allows it, forward the compressed result upstream for long-term storage, fleet-wide analytics and model training. The cloud keeps the roles it is good at: scale, history, training, cross-site comparison, and a single place for people to look. Edge analytics handles the moment-to-moment.
The trade-offs
The edge is not free. Hardware in the field has to be bought, powered, cooled, physically secured and replaced when it fails, and nobody is standing next to it when it does. Software has to be built for intermittent connectivity, limited resources and a heterogeneous mix of boards and operating systems. A fleet of a thousand edge gateways is a thousand small data centers to patch.
Security changes shape as well. A cloud region is behind a well-defended perimeter; an edge box may be in an unlocked cabinet. Secure boot, disk encryption, per-device identity and tamper detection move from nice-to-have to necessary, and the attack surface grows with every local service exposed on the site network.
Consistency is the subtle cost. When logic runs in many places, versions drift, local decisions diverge, and debugging a problem means reconstructing what each node believed at the time. Good edge platforms treat configuration and code as centrally versioned artifacts and make every node report what it is running.
Deciding what runs where
A practical rule of thumb: put a workload at the edge when at least one of the four forces applies strongly, and keep it in the cloud otherwise. A monthly energy report has no latency need, modest bandwidth, no resilience requirement and no privacy issue, so it stays in the cloud. A safety interlock has a hard latency need, so it stays on the controller. A camera-based quality check has a bandwidth problem and probably a privacy one, so inference runs on a gateway and only defect images go upstream.
Then ask who operates the hardware. If the customer’s IT team will own the edge box, keep it simple, standard and remotely manageable. If your own field team will, you can afford something more capable but must plan for spares and site visits. And prototype the connectivity failure mode first, not last, because that is where edge systems earn or lose their keep.
Where to go next
- Edge vs cloud vs fog gives a decision framework for placing computation across the layers.
- The IoT data pipeline shows where edge filtering and aggregation fit in the end-to-end flow.
- Edge AI explained covers the machine learning side of running intelligence on devices and gateways.
- Industrial IoT: a practical guide shows the edge in its most demanding setting.
Topics: edge computing, edge gateway, latency, architecture, edge AI