4  Choosing Edge, Fog, or Cloud

Placing IoT Workloads by Evidence

edge-fog
decision
framework
In 60 Seconds

Edge, fog, and cloud are placement choices for one workload at a time. Edge fits immediate local action. Fog fits site coordination, protocol translation, buffering, aggregation, and local operator context. Cloud fits fleet history, governance, analytics, audit, and cross-site comparison. A reviewable decision names the workload, the tier owner, the rejected alternatives, the evidence, degraded behavior, and the retest trigger.

4.1 Start Simple

Picture one workload, such as opening a valve, classifying a sound, or reconciling a batch of site readings. The core question is where that workload can be correct, timely, private, and supportable. Everyday IoT placement is not a vote for edge, fog, or cloud in general; it is a record for this one job. Start with one decision record that names the owner, the evidence, the rejected tiers, the degraded mode, and the condition that forces a retest.

4.2 Learning Objectives

By the end of this chapter, you will be able to:

  • State a placement decision as a workload claim, not a whole-system slogan.
  • Compare edge, fog, cloud, and split ownership by response, data, trust, connectivity, resources, and operations constraints.
  • Write a short placement record that another engineer can review later.
  • Design boundary tests for timing, state, management, command authority, and failure recovery.
Most Valuable Understanding

A tier choice is credible only when the normal path and the degraded path are both named. If the design cannot say what continues, what stops safely, what queues, what drops, and what remains explainable, the placement decision is not finished.

4.3 Placement Is a Workload Claim

Start by naming one action: sample, filter, infer, actuate, alert, aggregate, translate, buffer, display, train, audit, or update. Then decide which tier owns that action. Do not label the whole system as edge-first or cloud-first and force every function into that label.

A placement pattern map showing edge autonomy, fog coordination, cloud fleet services, split workloads, and evidence records
Figure 4.1: Placement pattern map for edge, fog, cloud, split workloads, and evidence records

4.3.1 Edge

Use edge ownership when a device must validate, decide, warn, actuate, or hold a safe local state without waiting for an upstream service.

4.3.2 Fog

Use fog ownership when a gateway or local server needs a group view, protocol boundary, buffer, site policy, or local operator context.

4.3.3 Cloud

Use cloud ownership when value comes from history, dashboards, analytics, model training, rollout policy, audit, or cross-site comparison.

4.3.4 Split

Use split ownership only when telemetry, commands, updates, fallback, replay, reconciliation, and evidence paths have named owners.

For example, an irrigation controller may keep pump shutoff at the edge because the field device must react during connectivity loss. A fog gateway may compare nearby pumps, soil sensors, and weather readings to detect site anomalies. Long-term water-use reporting can still live in the cloud. That is not one tier label; it is a set of workload claims with different evidence and owners.

Knowledge Check: Placement Claim

4.4 Build a Placement Record

A placement record turns architecture preference into reviewable evidence. Keep it short enough to maintain, but specific enough that another engineer can replay the reasoning after requirements, devices, links, policies, or cloud services change.

Edge-fog-cloud placement decision framework branching on latency requirement, per-device data rate, and device count to choose edge, fog gateway, or cloud processing.
Figure 4.2: Edge-fog-cloud placement decision framework: latency requirement, per-device data rate, and device count guide whether a workload runs on the edge, in a fog gateway, or in the cloud.

Record these fields before rollout:

  • Workload: The action being placed, such as alert, aggregate, translate, buffer, display, train, audit, or update.
  • Constraints: Response budget, data movement, trust boundary, connectivity, compute, power, storage, and operating limits.
  • Placement: Edge, fog, cloud, or split ownership, with rejected alternatives.
  • Paths: Telemetry, command, management, update, fallback, replay, and reconciliation paths.
  • Evidence: Measurements, outage drills, load tests, update practice, rollback checks, and retest triggers.
Placement record:
- Workload:
- Tier owner:
- Rejected alternatives:
- Response evidence:
- Data and evidence boundary:
- Trust and command boundary:
- Normal path:
- Degraded path:
- Update and rollback owner:
- Retest trigger:
Knowledge Check: Decision Record

4.5 Compare Constraints, Not Labels

The same workload may point to different tiers as the constraints change. Use the table as a review prompt, not as a formula.

Constraint Review Question Evidence to Keep Common Mistake
Response How quickly must the physical process or user receive a useful response? End-to-end timing, percentile behavior, queue delay, and degraded-path timing. Measuring only API latency while ignoring sampling, buffering, command delivery, and actuation.
Data Which raw records, summaries, events, and diagnostics must move or remain local? Freshness needs, retention rules, replay behavior, audit records, and loss handling. Dropping detailed evidence before diagnostics, compliance, or model improvement needs are known.
Trust Which tier may see, change, store, command, or delete data and device state? Identity, authorization, encryption, retention, command approval, and audit ownership. Treating gateway access as harmless because it is local.
Operations Who updates, monitors, rolls back, repairs, and retires each tier? Health signals, update records, rollback plan, support owner, and retest trigger. Choosing a clever placement that the field team cannot observe or recover.

4.6 Boundary Tests

The hard part of placement is not choosing a tier name. The hard part is proving the boundaries between tiers. A workload can fail because data arrives too late, the wrong tier owns authority, a gateway cannot recover state, an update breaks local behavior, or the cloud record cannot explain what happened during a disconnected period.

4.6.1 Timing Boundary

Measure the full path under normal load, queue pressure, link degradation, restart, and recovery. A single successful path test is not a latency budget.

4.6.2 State Boundary

Name which state is authoritative at the device, gateway, and cloud. Include conflict handling when a local decision happens before upstream reconciliation.

4.6.3 Management Boundary

Track configuration, firmware, model files, certificates, health checks, logs, and rollback signals as first-class traffic.

4.6.4 Failure Boundary

Define what continues, what stops safely, what queues, what drops, and what evidence is retained when WAN, LAN, broker, gateway, or cloud services fail.

Boundary Test What to Vary Pass Evidence Retest Trigger
Disconnected operation WAN loss, broker restart, gateway reboot, local storage pressure. Named local behavior, queued or summarized records, safe stop rule, and replay result. New gateway software, storage policy, broker path, or response requirement.
Command authority Allowed commands, stale commands, duplicate commands, denied identities. Command validation logs, rejection evidence, local override behavior, and audit trail. New actuator, role model, identity provider, or firmware version.
Evidence retention Filtering level, compression, sampling window, privacy rule, retention window. Review can still explain alerts, misses, outages, model decisions, and operator action. New analytics goal, compliance rule, support process, or privacy boundary.
Lifecycle change Update, rollback, replacement device, certificate rotation, model replacement. Known owner, rollback proof, version record, compatibility check, and health signal. New hardware revision, model runtime, gateway image, or cloud API contract.

A useful failure drill is concrete. Disconnect the WAN, restart the gateway, rotate a certificate, and send a stale command while the device is still sampling. The expected result should say which tier has authority, which records queue locally, which commands are rejected, what the operator sees, and how cloud state reconciles afterward.

Knowledge Check: Failure Boundary Tests

4.7 Summary

  • Edge-fog placement is a workload-level decision, not a whole-system label.
  • Edge usually owns immediate local action; fog usually owns site coordination; cloud usually owns fleet memory and governance.
  • Split designs are valid only when paths, owners, evidence, fallback, replay, and reconciliation are explicit.
  • A decision record should state the chosen tier, rejected alternatives, normal path, degraded path, proof, owner, and retest trigger.
  • Boundary tests make the placement decision maintainable after devices, links, policies, software, and support responsibilities change.
Key Takeaway

Do not choose edge, fog, or cloud by architecture preference alone. Choose a workload owner, prove the boundary with evidence, and reopen the decision when measurements, devices, links, policies, or operating responsibilities change.

4.8 See Also

Edge-Fog Latency

Build response budgets before assigning fast decisions to a tier.