Analytics & ML · Study deck
Edge Placement and Cost Contracts
Picture a food plant with a camera watching sealed packs.
Data Dora is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: A hard local deadline or loss-of-WAN requirement pushes the decision toward edge execution; shared context and moderate latency can support a fog or gateway tier; large historical analysis and elastic compute favour cloud placement.
- Explain: If the requirement is low monthly cost for high-rate sensors, the edge earns its place by reducing raw streams into summaries or events before the uplink.
- Explain: For an environmental logger that sends one hourly summary over reliable broadband, cloud-only may be acceptable because latency and bandwidth do not force local processing.
- Explain: Cloud still has a role.
Major section
Start With the Story
One job must stop a faulty pack before it leaves the line.
- The system owner must decide where each job runs and what each choice will cost.
- A fast stop may belong beside the line.
- A long study may use a distant service and a larger store.
- This opening does not choose hardware or prove the final bill.
Major section
Start With Failure Constraints
Practical edge design starts with a constraint, not with a preferred platform.
- If the requirement is low monthly cost for high-rate sensors, the edge earns its place by reducing raw streams into summaries or events before the uplink.
- If the requirement is privacy, the edge keeps sensitive raw data local and sends only derived features.
Major section
Start With Failure Constraints (continued)
The most useful sequence is latency first, then data volume, then privacy and operational ownership.
- Latency decides whether cloud is even eligible.
- Data volume decides whether cloud-only is affordable.
- Privacy decides what cannot leave the site.
- Intuition: the edge is justified when local action, local reduction, or local privacy changes the outcome.
Major section
Start With Failure Constraints (continued)
Operations decide whether the chosen edge hardware can be monitored, updated, and replaced without turning every gateway into an unmanaged mini data center.
- If none of those apply, cloud-first is usually cheaper and easier to operate.
- A hard local deadline or loss-of-WAN requirement pushes the decision toward edge execution; shared context and moderate latency can support a fog or gateway tier; large historical analysis and elastic compute favour cloud placement.
- Data volume and privacy can redirect any branch, while an explicit fallback may require work at more than one tier.
Major section
Start With Failure Constraints (continued)
The result continues the chapter's running narrative: placement is a failure contract with measured costs, not a permanent label attached to an algorithm.
- For a factory vibration system, a 20 ms machine stop belongs at the edge even if the cloud has better compute.
- For an environmental logger that sends one hourly summary over reliable broadband, cloud-only may be acceptable because latency and bandwidth do not force local processing.
- Good architecture is not "edge everywhere"; it is a deliberate split where each function runs at the cheapest tier that still meets the hard requirement.
Major section
Placement Requirements Worksheet
A gateway or fog node fits protocol translation, buffering, aggregation, and moderate inference across many sensors.
- The worksheet should name the function, deadline, raw data rate, reduced data rate, privacy classification, failure mode, and owner.
- It worsens when maintenance, spares, field replacement, or OTA operations are ignored.
- Device-local logic is best for deterministic control loops and safety interlocks.
Major section
Placement Requirements Worksheet (continued)
Worked example: when hardware pays for itself: The payback improves when local processing also avoids failed safety requirements, lowers storage volume, or reduces cloud inference.
- Cloud fits model training, long-horizon analytics, dashboards, and cross-site optimization.
- The edge decision should preserve the threshold version, input window, clock source, and model hash that justified an action.
- The cloud should preserve the training window, rollout version, and rollback rule that produced any model pushed down to devices.
Major section
Under the Hood: The Real Edge Cost Model
Latency risk is about worst-case behavior, not average behavior.
- A cloud path with a 150 ms average can spike above a second during congestion, DNS failures, cellular handover, or regional service incidents.
- Data reduction value depends on whether the edge keeps the right information.
- Hardware lifecycle is the part many estimates miss.
Major section
Under the Hood: The Real Edge Cost Model (continued)
Another deployment may be optional because cloud latency is acceptable, but edge reduction pays back quickly on bandwidth.
- If the control loop fails when the tail is bad, the function belongs locally even when cloud processing looks cheaper on a spreadsheet.
- Safety and control paths need deterministic local behavior.
- Reduction must preserve evidence.
Major section
Under the Hood: The Real Edge Cost Model (continued)
The cost model must therefore pair each reduction rule with the decision it still supports.
- A 95% reduction is useful only if summaries, features, or event windows preserve the diagnostic evidence that the cloud needs later.
- Gateways need spares, monitoring, certificates, OTA updates, rollback, field replacement, and security patching.
- Hardware is a fleet.
Major section
Under the Hood: The Real Edge Cost Model (continued)
Reducing a vibration stream to FFT peaks may be correct for bearing monitoring, but reducing it to a single average can destroy the fault signature.
- A $5,000 gateway purchase is not the total cost; it is the start of a fleet.
- Cloud still has a role.
- Another useful check is reversibility.
Major section
Under the Hood: The Real Edge Cost Model (continued)
Evidence quality closes the loop: each edge action needs enough local metadata to explain what happened when cloud records arrive later.
- Mixing those two arguments hides risk: the financial model can be adjusted, but a missed control deadline can make the architecture invalid.
- Filtering, aggregation, FFT features, and event clips are only valid when they retain the evidence needed for later decisions.
- One useful calculation is the break-even reduction factor.
Major section
Under the Hood: The Real Edge Cost Model (continued)
Edge nodes require health checks, certificates, OTA rollout, rollback, spares, and replacement procedures.
- Training, cross-site correlation, dashboards, and long-term storage often stay in the cloud even when action runs locally.
- If it also satisfies a hard safety requirement that cloud cannot meet, the decision may be justified even before the financial break-even point.
- Cloud services can often be resized or redeployed quickly; physical edge fleets cannot.
Deck summary
Key takeaways
One job must stop a faulty pack before it leaves the line.
- Practical edge design starts with a constraint, not with a preferred platform.
- The most useful sequence is latency first, then data volume, then privacy and operational ownership.
- Operations decide whether the chosen edge hardware can be monitored, updated, and replaced without turning every gateway into an unmanaged mini data center.
- The result continues the chapter's running narrative: placement is a failure contract with measured costs, not a permanent label attached to an algorithm.
Retrieval practice
Recall check 1 of 3
Data Dora says: answer from memory, then check your reasoning.
Q1Which practical question should usually be answered first when deciding whether a function belongs at the edge or in the cloud?
Show answer
Answer: A A hard latency or availability requirement can make cloud placement ineligible before cost comparisons matter.
Retrieval practice
Recall check 2 of 3
Data Dora says: answer from memory, then check your reasoning.
Q2A vibration system needs 20 ms shutdowns and weekly model retraining across all machines. Which placement is most practical?
Show answer
Answer: A The hard shutdown deadline belongs near the machine, while weekly retraining benefits from cloud history and compute.
Retrieval practice
Recall check 3 of 3
Data Dora says: answer from memory, then check your reasoning.
Q3Why is average cloud latency alone a weak basis for deciding that a safety function can run in the cloud?
Show answer
Answer: A Safety design must account for worst tolerated response and failure modes, not only average round-trip time.
Print reference
Answers
Answer key.
- A · A hard latency or availability requirement can make cloud placement ineligible before cost comparisons matter.
- A · The hard shutdown deadline belongs near the machine, while weekly retraining benefits from cloud history and compute.
- A · Safety design must account for worst tolerated response and failure modes, not only average round-trip time.