What “the edge” means
Edge computing means doing some of the processing close to where data is produced or used, instead of sending everything to a distant data centre. “Close” can mean several things: on the device itself, such as a sensor or camera; on a nearby gateway or small server in the same building; or in a regional facility run by a network or cloud provider that sits nearer to users than the main data centres.
The term is not precise, and vendors use it loosely. A helpful way to think about it is as a spectrum with the device at one end and a large central cloud at the other. Most real systems use points along that spectrum, not one extreme.
Cloud versus edge, in plain terms
In a typical cloud design, devices collect data and send it over the internet to a central service, which stores it, processes it and sends results back. This is flexible and easy to scale, and you do not maintain much hardware yourself.
In an edge design, some of that work happens locally. The device or gateway may filter, summarise, make a quick decision, or run a machine-learning model, and then send only what is needed onward. Edge usually complements the cloud and does not replace it: long-term storage, heavy analysis, fleet management and dashboards often remain in central services.
Why process data nearby
Latency
Every trip across a network takes time, and the time is not perfectly predictable. For tasks where a fast, consistent reaction matters, such as a machine that must stop when a sensor trips or a camera that must respond to what it sees, round trips to a distant server may be too slow or too variable. Processing locally cuts out that trip. For safety-related stops, a dedicated local control is the sensible design regardless; see the principles behind an emergency stop.
Bandwidth and cost
A camera or vibration sensor can generate far more raw data than is practical or affordable to upload continuously. Processing locally lets you send results (for example “motion detected at 14:02”) instead of constant video or high-rate signals. Whether this saves money depends on pricing and volumes, which vary, so work out the numbers for your own case.
Reliability
If the internet connection drops, a purely cloud-dependent system may stop working. A system with local processing can keep operating and sync later. For equipment in remote places or with patchy connectivity, this is often the main reason to use edge.
Privacy and data control
Keeping raw data on site can reduce what is exposed in transit and stored by third parties. A camera that only sends “a person was detected” rather than the footage is one example, though design and security still matter. The concerns raised in camera privacy and data encryption apply equally to edge devices.
Data rules
Some organisations face rules about where data may be stored or processed. Local processing can help, but legal requirements are specific, so check with a qualified adviser instead of assuming.
Where it shows up
Common examples include factory and building monitoring, retail and traffic cameras that run object detection locally, smart-home hubs, vehicles, health-monitoring devices, and content delivery that caches material near viewers. Hobbyist versions are everywhere too: a Raspberry Pi hub reading sensors and acting on rules is a small edge system. Machine learning is a frequent partner, since running inference on site can cut latency and data transfer, as covered in the notes on inference hardware and tiny machine learning.
The trade-offs
Edge is not free of costs. Be realistic about these.
- More things to manage. Instead of one central system, you have many devices, each needing updates, monitoring and replacement. Firmware updates become a continuing job, not a one-off.
- Limited resources. Local hardware has less compute, memory and storage than a data centre, so models and software may need to be smaller or simplified.
- Security surface. Devices in the field can be physically accessed, stolen or tampered with. Features like secure boot, unique credentials and encrypted storage matter, and default credentials are a well-known weakness.
- Consistency. Keeping software and data consistent across many sites is harder than in one place.
- Complexity. Splitting logic between device, gateway and cloud adds design decisions and more ways for things to fail.
- Upfront cost. Hardware, installation and maintenance have real costs that cloud usage may avoid.
Edge and the network
Faster mobile networks and local wireless links make edge designs more practical in some settings, but they are neither required nor a guarantee of better results. The role of 5G networks is worth understanding separately, and the choice among wireless protocols matters when devices are battery-powered or far from a router. Messaging between devices and gateways is often handled with MQTT messaging.
A way to decide
Ask these questions about each piece of processing.
- How fast does the response need to be, and how consistent?
- How much data is produced, and how much must really leave the site?
- What happens if the connection is down?
- How sensitive is the data, and who should see it?
- Can the device handle the work, and who will maintain it for years?
- Would a simpler cloud-only design do the job?
If the answers do not point clearly to local processing, start in the cloud and move specific pieces to the edge when you have a measured reason. Likewise, if you are pitched an “edge solution”, ask what problem it solves that you actually have and what evidence supports the claims. Edge computing is a useful tool for particular problems and not a general upgrade for every system.