Edge Computing
Edge computing is running compute and storage close to where data is produced, on a device, a gateway at the site or a telecom edge node, instead of only in a central cloud. Teams choose it when they need low latency, less data sent over the network, operation without connectivity or data that stays on site.
Key takeaways
- Processing moves to the device, a site gateway or a telecom edge node
- Four reasons to use it: latency, bandwidth, offline operation and data kept on site
- Fog computing is the layer between end devices and the cloud
- Multi-access edge computing (MEC) is the mobile network's edge, standardized at ETSI
- Edge software must expect lost connectivity, remote updates and physical tampering
What Edge Computing means
In a cloud-only design, every sensor reading or camera frame travels to a data center before anything happens. Edge computing moves some of that work closer to the source, so a machine can react at once and send only results, summaries or exceptions upstream.
The edge is a place, not a product. It can be the device itself, a gateway computer in a plant, clinic or building, a fog node that serves several sites, or compute run by a mobile network operator near its cell sites. Most real systems pair an edge tier with a cloud tier rather than choosing one.
Agnotic Technologies builds edge software for connected products and industrial clients, from gateway services to the cloud side that manages them. How data travels from a device to the cloud and how over-the-air updates roll out are covered on our IoT product development services page.
Why process data at the edge?
There are four reasons, and a design usually needs at least one of them to justify the extra moving parts.
Latency: a control loop or a safety stop cannot wait for a round trip to a distant cloud region.
Bandwidth: video and high-rate vibration data cost more to send than to summarize locally.
Offline operation: a site with an unreliable link has to keep working and catch up later.
Data kept on site: some owners want raw data to stay inside the facility and only results to leave it.
If none of these apply, a cloud-only design is simpler to build and run.
What changes when software runs on edge nodes?
Connectivity comes and goes. The node stores data and forwards it when the link returns, keeping timestamps from the source and handling duplicates safely.
Updates are remote. Every node must accept signed updates, report its version and fall back to the last good release if an update fails.
Hardware is limited. Services and models are sized for the node's memory and processor, not for a cloud instance.
Someone can touch it. A box in a plant or a clinic can be unplugged, opened or carried away, so disks are encrypted, unused ports are closed and every node has its own credentials.
How is edge computing used on a production line?
Take a production line where cameras inspect parts. Sending every frame to the cloud would use most of the site's uplink and add delay before a reject signal.
A gateway on the line runs the inspection model, signals the reject gate locally and sends only defect images and hourly counts to the cloud. The cloud side retrains the model and pushes new versions back to the gateway.
Where should processing run: device, gateway, fog or cloud?
Most systems split work across several tiers. The latency and connectivity a workload needs decide where it belongs.
| Tier | Latency need | Connectivity it can assume | Workload that belongs there |
|---|---|---|---|
| Device | Immediate, inside the device's own control loop | None; it must work alone | Sensor filtering, safety cutoffs and simple thresholds |
| Edge gateway on site | Very low, within the site network | Local network; the uplink may drop | Protocol translation, local dashboards, inference on site data, store and forward |
| Fog or MEC node | Low, a few network hops away | A regional or mobile operator network | Work shared by many sites or devices, such as video analytics for a campus or a vehicle fleet |
| Cloud region | Tolerates network round trips | Expected, but not guaranteed from every site | Fleet management, model training, long-term storage and analytics across sites |
Facts and primary sources
NIST SP 500-325, the Fog Computing Conceptual Model, describes fog computing as decentralizing applications, management and data analytics into the network itself, and defines fog and mist computing in relation to cloud models for IoT.
Source: NIST SP 500-325ETSI's Multi-access Edge Computing (MEC) Industry Specification Group develops standards for an open environment in which applications from infrastructure and edge service providers run across multi-vendor MEC platforms.
Source: ETSI Multi-access Edge ComputingAWS documentation describes AWS IoT Greengrass as an open source edge runtime and cloud service that lets devices act locally on the data they generate and react on their own to local events.
Source: AWS IoT Greengrass Developer GuideMicrosoft documentation describes Azure IoT Edge as a device-focused runtime for deploying, running and monitoring containerized Linux applications on devices, for faster insights and offline decision-making.
Source: Microsoft Learn, Azure IoT Edge
Explore this on Agnotic
Where Edge Computing shows up in how we build.