A camera above a conveyor belt catches a mislabeled carton, and a robotic arm has roughly 20 milliseconds to knock it off the line. Send that video frame to a data center two states away and back, and the carton is already on a truck. Run the same check on a small industrial computer bolted to the machine frame, and the arm gets its answer in time to act.
Most teams hit this fork in the road early: keep processing close to the equipment, or centralize it somewhere cheap and elastic. Neither answer is wrong. They're right for different workloads, and knowing which is which before you buy hardware or sign a contract saves a lot of rework.
Where the edge sits, and where the cloud sits
Edge computing means placing compute and storage physically near the thing producing or consuming the data. In practice that covers a wide range of locations. It might be a sensor or gateway on the machine itself, a cabinet in the plant's electrical room, a small server in a retail back office, or a regional point of presence owned by a carrier or colocation provider. The cloud is the opposite arrangement: a handful of large, centralized facilities that you reach over the public internet.
The cloud wins on elasticity and operational abstraction. Need ten times the capacity next Tuesday? Ask for it. Need someone else to replace a failed disk at 3 a.m.? Already handled. Security patching, capacity planning, and hardware failure are largely the provider's problem, which is exactly why so much of the world's software lives there.
Edge isn't a replacement for the cloud, and treating it as one leads to awkward architectures. The usual pattern is a control plane in the cloud — dashboards, model training, device management, long-term storage — with a data plane at the edge that keeps running when the connection drops.
Latency: physics first, engineering second
Light travels through fiber at roughly 200,000 kilometers per second, so a 1,000-kilometer round trip costs about 10 milliseconds before a single router gets involved. Real networks add queuing, handshakes, and TLS negotiation on top of that. A typical cross-region cloud round trip lands somewhere in the tens of milliseconds, while a local edge node on the same site can answer in single digits, sometimes under a millisecond.
Plenty of workloads don't care. Nightly analytics, backup jobs, image uploads, and customer records all tolerate a few hundred milliseconds of extra travel without anyone noticing. Workloads that do care tend to involve a physical action: safety interlocks, motion control, live video analytics that triggers an alarm or a gate, augmented reality overlays, and conversational interfaces where a delay feels like a dropped connection.
Watch the tail, not the average
Averages hide the problem. A control loop cares about its worst case, so the 99th percentile matters far more than the median. If latency spikes whenever a backup job runs or a neighbor saturates the uplink, that spike is the number that determines whether your system works. Keeping the processing loop on the local network removes most of the places where queues can form.
Bandwidth: stop shipping raw data
Twenty cameras streaming four megabits per second each is roughly 80 megabits per second of sustained upload. That's a dedicated circuit in many buildings, and it runs continuously whether anything interesting is happening or not. Move the first filter to the edge and the arithmetic changes completely.
- Send counts, classifications, and anomaly events instead of full frame streams.
- Keep a rolling local buffer so you can upload the 30 seconds around an event, not the whole day.
- Transcode or downsample high-resolution footage before it leaves the site.
- Aggregate readings from hundreds of sensors into one compressed batch.
- Schedule bulk uploads for overnight windows when the link is quiet.
Cost matters here as much as capacity. Cloud providers generally charge for data leaving their network, so an architecture that streams everything into the cloud and pulls it back out again is the most expensive shape you can draw. Filtering at the source reduces storage bills, egress bills, and circuit costs at the same time.
Cost: three bills, not one
Cloud spending is operational and granular. You pay for what you use, capacity follows demand, and there's no capital outlay. Edge spending is lumpier: hardware, power, cooling, physical security, spares, and the truck roll to fix something on-site. Add fleet management software, and the per-site cost stops being about the box at all.
A useful rule of thumb is that the decision hinges on two numbers: how much data each site generates per month, and how many sites you operate. With a handful of locations, edge hardware is often a rounding error next to the operational burden. With thousands of locations, the opposite is true — standardization, remote recovery, and support logistics dominate the budget, and a slightly more expensive device that never needs a site visit is usually the cheaper choice.
Management and reliability: you inherit the failure modes
In the cloud you rent reliability. At the edge you own the failure domain, and that domain includes people who unplug things to charge a phone, breakers that trip, and firmware updates that fail at two in the morning in a building with nobody on staff to fix them.
Design accordingly. Never let a safety-critical function depend on the WAN. Buffer locally and forward when the link returns. Provide out-of-band access so you can reach a device that isn't answering. Use A/B partitions and a watchdog so a bad update rolls back on its own. Keep one or two spare units per region rather than one per site. Write down the physical repair procedure, because eventually someone will have to follow it.
Physical access also changes the security model. Signed firmware images, encrypted disks, secure boot, no default credentials, and a working way to revoke a device that walks out the door are baseline requirements, not extras.
A placement checklist
- Does the workload have a deadline measured in milliseconds? If yes, it belongs close to the action.
- How much data does each site produce per day, and how much of it does anyone actually need centrally?
- What should happen if the site loses connectivity for an hour — keep working or stop safely?
- Who can physically reach the hardware, and how quickly?
- What does one site cost per year to run, including power, spares, and support time?
- Can the workload run as a container in both places, so you can move it later without a rewrite?
- Are there privacy or data-residency rules that favor keeping raw data local?
Start with one workload and measure it
Pick a single site and a single workload. Instrument three things before you decide anything: round-trip latency to your cloud region, the volume of data leaving the site each day, and the hours your team spends keeping it running. Those three numbers will tell you more than any architecture diagram.
A good first move is a modest aggregation layer at one site: collect the sensor or camera data locally, filter it, and forward only what matters. Keep the cloud as the control plane, run the same container images in both places, and revisit the split after a quarter of real operation. Most teams find that a small fraction of workloads genuinely need the edge — and that those few benefit enormously from being there.
Photo: GrownDiamond / Pixabay
