Edge computing vs cloud computing for IoT: where the work should happen

Someone in the meeting says the data should be processed “at the edge”, someone else says it should all go to the cloud, and both are describing real systems that work. The disagreement is usually about where one particular job should run, and that is a question with a clear method behind it. This article defines the two terms without the marketing, sets out the differences that actually decide the split, and gives a way to place each job in your own system.

What edge computing and cloud computing mean

Cloud computing means running software on servers you rent from a provider, reached over the internet, that scale up and down on demand. The United States National Institute of Standards and Technology published the definition most people still use, with its five characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service (NIST Special Publication 800-145). For an IoT system the cloud is where the historian, the dashboards, the analytics and the fleet management usually live, because those jobs want all the data in one place and want compute that grows with it.

Edge computing means running software close to where the data is produced: on the device itself, on a gateway in the same building, or on a server at the site. “Edge” is a relative term, and it helps to name which edge you mean. The device edge is the sensor node or the machine controller. The gateway edge is the box that collects from many devices and speaks to the network. The site edge is a server in the plant or the store. Beyond that, some network operators offer compute inside their own networks, a few hops closer than a cloud region; the industry body that standardized that model calls it multi-access edge computing, and the Linux Foundation’s LF Edge projects cover the open-source software for the layers below it.

The two are not rivals for the same job. They are places, and each job in a system has a place where it belongs.

Edge computing vs cloud computing: the differences that matter

Five differences decide where a job belongs. The others are details.

Latency. A control loop that must react within milliseconds cannot wait for a round trip to a cloud region, which takes tens to hundreds of milliseconds and varies. Anything that closes a loop on a machine, trips an alarm, or reacts to a person walking into a room belongs at the edge. Anything that a human will look at after a cup of coffee can go to the cloud.

Bandwidth and its cost. A vibration sensor sampling thousands of times a second produces far more data than anyone wants to ship over a cellular link. Processing at the edge reduces that to a handful of features per minute. The rule is that raw data is cheap to produce and expensive to move, so reduction belongs as close to the source as possible.

Reliability when the link is down. A plant on a single internet connection loses that connection sometimes. If the lights, the line or the alarm depend on the cloud, they stop. Anything that must keep working during an outage runs at the edge, and the edge buffers what the cloud will want later.

Scale and compute. Training a model across a year of data from a hundred sites, running a fleet-wide report, or storing everything indefinitely wants elastic compute and storage. That is what the cloud sells. An edge box has fixed capacity and someone has to visit it to change that.

Data governance and privacy. Some data cannot leave the site, by law or by policy, or is simply not worth the exposure. A camera that counts people at the edge and sends only the count keeps the images where they were taken.

Cost cuts across all five and rarely decides on its own. Cloud costs scale with data volume and compute time; edge costs are hardware, installation and someone to maintain boxes in the field. A system that ships everything to the cloud pays in bandwidth and storage forever; a system that does everything at the edge pays in visits and in the analysis it never does.

When edge computing wins

Edge is the right place for the jobs below, and the article on what an industrial IoT system is made of shows where each sits in the layer stack.

Anything in a control loop. Reading a sensor and acting on it, whether that means a valve, a drive or a relay, happens on a controller in the same cabinet. The cloud may set the setpoint; it never closes the loop.

Filtering, aggregation and feature extraction. Turning a fast raw signal into the few numbers that carry meaning: an overall vibration level, an average temperature, a count of events. The gateway does this and sends the result.

Local alarms and safety-adjacent alerts. A high-temperature alarm should sound in the building whether or not the internet is up.

Buffering. A gateway that stores readings during an outage and forwards them afterward, so the historian has no gap.

Protocol conversion. Reading a fieldbus or an OPC UA server and publishing MQTT, as the OPC UA and MQTT article describes, is an edge job by definition.

Privacy-preserving processing. Vision and audio analysis whose output is a count, a category or a yes-or-no, with the raw material never leaving the site.

Sites with poor connectivity. A remote pumping station on a slow link needs to be useful on its own and to send summaries when it can.

When cloud computing wins

History and long-term storage. A historian that holds years of data from every site, queryable from anywhere, is a cloud job. Edge storage is for buffering, not for archives.

Analytics that need all the data. Comparing machines across sites, finding which of fifty pumps behaves oddly, training a model on last year’s failures: these want the whole dataset and elastic compute.

Fleet management. Knowing which devices are online, which firmware they run, and pushing updates to them, is naturally centralized. The firmware update article covers the device side of that.

Dashboards for people in many places. An operations manager, a regional team and a vendor’s support desk all looking at the same numbers want one place to look.

Integration with other business systems. Maintenance tickets, inventory, billing and customer systems already live in the cloud or in a data center; the IoT data joins them there.

Anything experimental. Trying a new analysis on real data is cheap in the cloud and expensive at the edge, where a change means a deployment to boxes in the field.

The usual answer: both, in layers

Real systems are layered, and the layers map onto the three places in the diagram. The device edge samples, filters and controls. The gateway or site edge aggregates, buffers, converts protocols and drives local displays and alarms. The cloud stores, analyzes, manages the fleet and serves the people who are not on site.

Data thins out as it moves right through the layers. A machine might produce thousands of samples a second at the device, a summary every few seconds at the gateway, and a minute-by-minute record in the cloud, with the raw waveform kept only when something looked wrong. Decisions move the other way: the cloud sets policies and setpoints, the edge executes them. That arrangement gives fast local behavior, resilience when the link drops, and a complete picture for the people who need one.

Two design rules keep a layered system honest. Every layer must be useful on its own if the layer to its right disappears: a gateway with no cloud still runs the site, a device with no gateway still controls its machine. And the interface between layers should be a published, boring protocol, usually MQTT with an agreed topic and payload convention, so that layers can be replaced independently. The MQTT explainer covers the conventions that make that work.

Where fog computing fits

Fog computing is a name for that middle layer. Cisco introduced the term around 2012 to describe computing, storage and networking spread across the nodes between devices and the cloud: gateways, routers, industrial PCs and local servers. The OpenFog Consortium, formed in 2015, wrote a reference architecture for it that the IEEE adopted in 2018 as IEEE 1934, and the consortium merged into the Industrial Internet Consortium the following year.

The difference from edge computing is mostly one of emphasis. Edge computing, as most people use it, means running work on or right next to the device: inside the sensor, the controller or the gateway that sits beside the machine. Fog computing describes the whole layer between that point and the cloud as one system, with many nodes at different levels that share work, pass data between each other and are managed together. A site server that collects from twenty gateways, runs analytics across a whole plant and forwards summaries to the cloud is the textbook fog node.

In practice the word “edge” has absorbed most of what “fog” was coined to describe, and vendors now sell edge platforms that manage fleets of gateways and site servers in exactly that layered way. The term still turns up in research papers, in standards and in some product literature. When someone proposes a fog architecture, the same questions as above settle the design: which job runs on which box, what each layer does when the one above it is unreachable, and how the boxes are updated.

How to decide for your system

Take the list of jobs your system has to do, and for each one ask four questions in order.

1. Must it keep working when the internet is down? If yes, it runs at the edge. This question alone settles control, alarms and local displays.
2. Must it react faster than a network round trip? If yes, it runs at the edge, and probably on the device rather than the gateway.
3. Does it need data from more than one site, or more compute than a box in a cabinet can hold? If yes, it runs in the cloud, on data the edge has already reduced.
4. Is the raw data too big, too sensitive, or too expensive to send? If yes, the reduction runs at the edge and only the result travels.

Jobs that answer no to all four can run in either place, and the tie-breaker is operational: where is it easier to deploy, update and watch? For most teams that is the cloud, because updating a hundred edge boxes is harder than updating one service.

A worked example makes the method concrete. Take a food distributor with six cold stores, each with a dozen temperature sensors, door contacts and a compressor. The jobs are: read the sensors, alarm when a room drifts warm, log every reading for the food safety audit, show the site manager the current state, show head office all six sites, spot a compressor that is starting to struggle, and push firmware to the sensors when needed.

Run the questions. The alarm must work when the internet is down and must react within a minute, so it runs at the site edge, on the gateway, with a local siren and a local display. Reading the sensors happens on the sensor nodes, obviously, and the gateway buffers readings during an outage. The site manager’s display is a local page served by the gateway, for the same reason. The audit log needs every reading kept for years and queried by an auditor who is not on site, so it lives in the cloud, fed from the gateway’s buffer so an outage leaves no gap. Head office’s view of six sites needs data from all of them, so that is cloud. Spotting a struggling compressor means comparing this week with last month and this site with the others, which is cloud analytics on data the gateway has already reduced to a few features per hour. Firmware management is a fleet job, so that is cloud too, with the gateway handling the last hop as the firmware update article describes.

The result is two rows at the device, three at the gateway and four in the cloud, and nobody had to argue about edge versus cloud in the abstract. Each job went where its constraints sent it.

Write the answers into a table with one row per job and a column for the place. That table is the architecture. It will change as the system grows, but a system that starts from it will not end up with a control loop in a cloud region or a year of raw waveforms on an SD card in a cabinet, which are the two failures the edge-versus-cloud argument is really about.