The basic idea
Cloud computing, in NIST’s definition, gives on-demand network access to a shared pool of computing resources, such as servers, storage and applications. That pool sits in data centres, which can be far from the people and devices that use it. Every request travels there and back, and every reading a device produces has to make the trip before anything can be done with it.
Edge computing moves some of that work closer to where the data starts. The term covers a wide range of places, from code running on the device itself to servers installed inside a mobile operator’s network, and different standards bodies draw the lines differently, as the two framings below show.
Edge, fog and mist in NIST’s model
NIST’s Fog Computing Conceptual Model (SP 500-325) describes layers between devices and the cloud:
- Edge is the network layer made up of the end devices and their users, providing for example local computing on a sensor, a meter or another network-accessible device. NIST notes that this layer is also referred to as the IoT network.
- Fog is a layer of fog nodes, physical or virtual, that sit between the end devices and centralised cloud services. They provide local computing resources to the devices and, when needed, connectivity onward to the cloud.
- Mist is a lightweight form of fog that sits at the very edge of the network fabric, using microcomputers and microcontrollers that feed into fog nodes.
NIST also says that fog is not a mandatory layer, and that a cloud service is not required for a fog layer to support the devices. Among the attributes it lists for fog nodes is autonomy, the ability to operate independently and make local decisions.
The network edge: ETSI MEC
In telecom standards, “edge” means the edge of the operator’s network. ETSI’s Multi-access Edge Computing (MEC) group describes MEC as offering application developers “cloud-computing capabilities and an IT service environment at the edge of the network”, with IT and cloud resources placed within the radio access network. ETSI notes that deployments can range from on-premise edge to network edge, and that MEC is not only for mobile networks but also for fixed and wireless LAN access. Its framework specification, GS MEC 003, defines the reference architecture for running applications on such a system.
| Where the work runs | Example | Term and source |
|---|---|---|
| On the device | An app on a phone, firmware on a sensor | Edge layer (NIST) |
| Small nodes beside the devices | A microcontroller board feeding a gateway | Mist (NIST) |
| Near the devices | A gateway or local server on site | Fog (NIST) |
| In the access network | Servers at an operator’s network edge | MEC (ETSI) |
| In a data centre | A hosted backend | Cloud (NIST) |
Why do work at the edge
- Latency. A decision made on the device, or one hop away, does not wait for a round trip to a distant data centre. NIST describes fog computing as minimising the request-response time for the applications it supports.
- Bandwidth. A device or gateway that filters, aggregates or summarises data sends less over its backhaul, the link that connects it to the wider network.
- Working through disconnection. If the logic runs locally, it keeps running when the link to the cloud is down. This is the same goal as local-first software, applied to computing rather than to documents.
- Keeping data local. Data that is processed where it is created does not have to be sent anywhere. That can reduce what has to be protected in transit and in central storage, though it moves the job of protecting it onto the device.
What edge computing does not solve
Moving work to the edge spreads it across more machines, and that brings costs of its own. Devices at the edge have less storage, memory and power than a data centre, and they may be physically reachable by anyone. Software has to be updated across every one of them. State held on separate devices has to be reconciled, which raises the same questions as offline sync. And results produced at the edge may still need to reach a central system eventually, which brings back the problem of collecting device data without internet.
One practical split is a mix: decisions that must be fast or must survive disconnection run at the edge, and records that need a single authoritative copy are reconciled with a backend later.