6 Edge-Fog Use Cases: Decision Framework

6.5.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.

Edge Eddie

“Send the decision, not the raw feed — the edge earns its keep in milliseconds and megabytes saved.”

Here Eddie checks each workload claim against its record: who owns it, what evidence backs it, and what happens when the tier degrades.

6.5.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.

6.5.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.

Inspect Figure 6.1 before continuing. Calling an architecture edge-first hides the fact that different actions can have different owners. Figure 6.1 helps decompose one workload before the placement record is written.

In the diagram Figure 6.1, Edge is paired with local autonomy, Fog with site coordination, and Cloud with fleet services. The Split path connects those roles instead of forcing the whole workload into one tier, and the Evidence record captures measurements and failure tests for the chosen division. The map therefore turns verbs such as infer, buffer, aggregate, and train into separate ownership claims that can be checked when requirements change.

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.

6.5.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.

Inspect Figure 6.2 before continuing. A placement record needs a reproducible route from measurements to ownership. Figure 6.2 provides a first-pass branching model that the team can annotate with its own observed values.

In the diagram Figure 6.2, the IoT Processing Decision first branches on Latency Requirement?: critical work under 10 ms points to Edge, while looser cases continue. The next tests use Data Rate per Device? and Number of Devices? to distinguish lightweight edge filtering, fog aggregation, direct cloud, or cloud processing. The lower cost-and-performance comparison is context, not proof; its role is to prompt project-specific latency, bandwidth, and operating-cost measurements in the final record.

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:

6.5.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.

6.5.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.

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.

6.5.7 Summary

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

6.5.8 See Also