Edge computing is often presented as a replacement for the cloud. In practice it is a placement decision: for each piece of logic in your system, where should it run? Putting everything in the cloud is simple but may be slow, costly or fragile. Putting everything at the edge multiplies the number of places you must operate software. Good designs split the work deliberately.

What “Edge” Means Here

In IoT, the edge usually means compute located near the devices: a gateway in a building, a small industrial computer on a machine, or capable logic inside the device itself. It sits between constrained sensors and the cloud. It can filter, aggregate, decide and act locally, then forward only what the cloud needs.

Four Forces That Pull Work Toward the Edge

Latency. If a decision must be made faster than a round trip to the cloud allows, it needs to happen locally. Equipment protection and closed-loop control are typical cases.

Bandwidth and cost. Streaming raw high-rate data such as vibration or video to the cloud can be expensive or impossible on limited links. Local processing can reduce it to events and summaries.

Autonomy. Sites with unreliable connectivity must keep working when the link drops. Logic that depends on the cloud will stop with it.

Data locality. Some data is subject to privacy or sovereignty requirements that favour processing it near its origin. Requirements vary by jurisdiction, so consult qualified advisers for your situation.

Four Forces That Pull Work Toward the Cloud

Fleet-wide view. Anything that needs data from many sites, such as comparisons, forecasting or model training, belongs where the data converges.

Elastic compute. Heavy, occasional jobs are cheaper to run on rented capacity than on hardware you must buy for peak load.

Operational simplicity. Software running in one place is easier to update, monitor and secure than software scattered across hundreds of sites.

Rapid change. Logic that you expect to revise often is better kept where deployment is cheap.

A Placement Guide

Workload	Usually best at	Reason
Safety interlocks and fast control loops	Edge or device	Cannot depend on network latency or availability
Protocol translation from local buses	Edge gateway	Needs local access to equipment
Filtering and aggregation of raw streams	Edge	Reduces bandwidth and cloud load
Local alerting during outages	Edge	Must work offline
Fleet analytics and dashboards	Cloud	Needs data from many sites
Model training	Cloud	Needs large datasets and elastic compute
Model inference	Either	Depends on latency, size and connectivity
Device registry and configuration management	Cloud	Central source of truth

Treat this as a starting point, not a rule. Individual systems will differ.

The Costs of Running Code at the Edge

Edge deployments are powerful, but every site becomes part of your operations surface.

• Updates. You need a safe way to deploy software and configuration to remote gateways, including rollback.
• Observability. Logs and metrics must be collected from places with limited connectivity.
• Security. Gateways are physically accessible and often sit on customer networks. Treat them as exposed.
• Heterogeneity. Different hardware, operating systems and network setups multiply testing effort.
• State. Local databases, queues and caches need backup and recovery plans.

If you cannot update and monitor an edge node reliably, it is a liability, however clever its logic.

Containers and Orchestration at the Edge

Many teams package edge logic in containers so the same artifact runs in development and in the field. Lightweight orchestrators exist for managing fleets of small nodes. Whether you need one depends on scale: a handful of gateways may be fine with simple scripted deployment, while hundreds benefit from declarative, pull-based management in which each node fetches its desired state. Check current documentation for the tools you consider, as the landscape changes.

A Hypothetical Example

Imagine a company monitoring refrigeration units across many stores. Each store has a gateway that reads temperature from several units. The gateway checks readings locally and triggers a local alarm immediately if a threshold is exceeded, even if the internet is down. It sends summarized readings to the cloud every few minutes and uploads detailed data only when an anomaly occurs. The cloud holds the fleet dashboard, compares performance across stores, and distributes updated alert thresholds. Safety-relevant logic lives at the edge, while analysis and configuration live centrally.

Designing for Both Sides

Keep the interface between edge and cloud narrow and well defined. Define what the edge reports, what it accepts as configuration, and how it behaves when disconnected. Store-and-forward queues should have size limits and a clear policy for what to drop when full. Give edge logic safe defaults so a gateway that cannot reach the cloud keeps operating on its last known configuration.

Frequently Asked Questions

Is edge computing always cheaper than sending data to the cloud? No. It can reduce bandwidth and cloud processing costs, but adds hardware, deployment and maintenance. Compare total cost, not a single line item.

Can I run machine learning at the edge? Often yes, particularly inference with compact models. Training usually happens in the cloud. Check the capabilities of your target hardware.

What happens to edge logic when the network drops? It should keep working on local data and queue results for later delivery. Design and test this behaviour explicitly.

Do I need a gateway if devices connect directly to the cloud? Not necessarily. Gateways help when devices use local protocols, lack direct internet access, or need local decision-making.

How do I secure remote edge nodes? Use unique identities, signed updates, minimal exposed services and encrypted communication, and plan for physical tampering.

Next Step

List the ten most important functions in your IoT system and assign each to device, edge, or cloud using the four forces above. Look for any function placed in the cloud that would be dangerous or costly to lose during an outage, and consider moving that one first.