Edge Computing: Why Compute Is Moving Closer to the Data

For twenty years the story of computing was centralisation: pull everything into big data centres where it's cheap to run and easy to manage. Edge computing is the counter-move. It puts processing back out near where data is produced — in factories, vehicles, shops, cell towers and on devices themselves — because for a growing class of applications the round trip to the cloud is too slow, too expensive or not allowed.

Why compute is moving outward

Three pressures, usually in combination:

• Latency. A round trip to a cloud region is typically 20–100 ms. A robot arm, a vehicle's collision-avoidance system or an AR headset rendering at 90 Hz can't wait that long. Physics, not engineering, sets the limit.
• Bandwidth and cost. A single 4K camera produces tens of gigabytes a day. A factory with 500 sensors, a fleet of vehicles or a retail chain can't ship raw streams to the cloud economically. Processing locally and sending only events or summaries can cut transfer by orders of magnitude.
• Privacy and sovereignty. Regulations such as GDPR and sector rules in healthcare and finance restrict where data can go. Processing it on site — and discarding what isn't needed — is often the simplest compliant design.

A fourth reason gets less attention: resilience. A site that keeps working when its uplink fails is worth a lot to a hospital, a mine or a ship.

The layers of an edge architecture

"The edge" isn't one place; it's a continuum between the device and the cloud.

• Device edge: the sensor, camera, phone or controller itself. Constrained power and compute; this is the domain of TinyML and on-device inference.
• Local/on-premises edge: a gateway or small server rack on site — a factory floor, a store, a hospital ward. Aggregates devices, runs heavier analytics, buffers data during outages.
• Network edge: compute hosted inside the telecom network, close to cell towers, often called multi-access edge computing (MEC). Enabled by 5G and used for low-latency services to mobile devices.
• Regional edge / CDN: points of presence in many cities, where content delivery networks now run application logic — the "edge functions" offered by Cloudflare, Fastly, Vercel and others.

Good designs decide explicitly which work runs where: real-time control and filtering at the device or local edge, aggregation and model retraining in the cloud, and a clear contract for what flows between them.

Edge and the Internet of Things

IoT is what made edge computing necessary. A modern plant might have thousands of sensors reporting vibration, temperature and current draw many times per second. At the edge, that stream is filtered, features are extracted and anomaly models run continuously; only exceptions and hourly summaries go upstream. This is how predictive maintenance works in practice — a bearing's vibration signature drifts, a local model flags it, and a work order is raised days before failure. The same pattern powers quality inspection on production lines, energy optimisation in buildings, and traffic management in cities.

Operating the edge

The hard part of edge computing is not the compute; it's managing thousands of small deployments you can't walk over to. The problems and their current answers:

• Fleet management. Lightweight Kubernetes distributions (k3s, MicroK8s) and cloud-vendor agents (AWS IoT Greengrass, Azure IoT Edge) let you deploy and update workloads across sites the way you would across cloud nodes.
• Security. Edge boxes sit in physically accessible places on networks you don't fully control. Secure boot, hardware identity, encrypted storage, and zero-trust network access are the baseline — see IoT Security.
• Data consistency. Sites go offline. Designs must tolerate intermittent connectivity: local buffering, idempotent uploads and conflict resolution when the link returns.
• Observability. You need logs, metrics and health signals from every site, sampled and compressed so monitoring doesn't consume the bandwidth you were saving.

Edge AI and what's next

The most visible change in edge computing is that the workloads are increasingly models, not rules. Vision models on cameras, speech models on devices, anomaly detectors on gateways — all made practical by neural processing units in commodity hardware and by compression techniques that shrink models tenfold with little accuracy loss. Edge AI covers that in detail.

Looking forward, the boundary between edge and cloud is blurring into a single programmable fabric: you write the workload once and a scheduler places it where latency, cost and data rules say it should run. That's the promise, at least. The reality today is still a lot of bespoke integration — which is exactly where the opportunity is.