Edge & Fog Computing · Study deck

Edge, Fog, and Cloud: Operating at Scale

Imagine twenty shops that each set a freezer limit locally while a central team also sends a new limit.

Edge Eddie is your guide for this deck.

cloudtopics

Edge Eddie, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Design local discovery and failover paths without making the cloud registry a runtime dependency for every device.
Classify state by authority, merge behavior, and safety impact.
Identify trust boundaries and tier-specific security controls across edge, fog, and cloud.
Choose where advanced workloads belong and define graceful degradation for each placement.

Major section

In 60 Seconds · Start Simple

One shop loses its outside link during the change.

When it returns, two valid records disagree.
Telemetry means facts a device sends so its state can be observed: Keep the source, time, unit, quality, and software version with each fact.
A delayed record must not look like a new event.

Major section

Minimum Viable Understanding · Most Valuable Understanding

Discovery is a dependency: Devices need a local way to find services, a remembered last-known-good path, and an operational registry that does not become a runtime single point of failure.

Security follows trust boundaries: Edge, fog, and cloud each need independent identity, least privilege, update controls, logging, and key management.
Orchestration is placement plus fallback: Workload scheduling is useful only when the fallback behavior is defined for overloaded, offline, or outdated tiers.
Observability must work locally: Operators need queue depth, retry rate, clock drift, model version, policy version, and dropped-record signals even when cloud dashboards are stale.

Major section

Advanced Production Map · Service Discovery and Failover

The closing label, Contracts make failures recoverable, connects the map to the chapter's production claim: each concern needs an owner and a failure contract, not simply a tier name.

Devices find local services, remember usable paths, and fail over without depending on a remote lookup for every reconnection.

Advanced edge-fog-cloud production concerns

Major section

State Authority and Consistency · Security and Trust Boundaries

Network partitions are normal in distributed IoT.

A site may keep operating while the cloud view is stale.
The important question is not whether divergence can happen; it is which state may diverge, who may change it, and how the system reconciles afterward.
The cloud receives a replica, not the source of truth.

State authority patterns across edge, fog, and cloud

Major section

Orchestration and Placement Fallback · Observability, Updates, and Governance · Decision Record

A safety command path, credential update, or audit ledger usually needs stronger authority than an opportunistic swarm can provide.

BitTorrent-style swarms, tree overlays, and multi-tree overlays are useful analogies because they make the tradeoff visible.
The throughput model must match the shared medium.
Hysteresis makes the client less reactive.

Major section

Fleet Operations and Edge Autonomy · Label the Diagram: Advanced Concerns · Code Challenge: State Authority Classifier

One edge device is a programming problem; a fleet is an operations problem.

At scale, the design must deploy, update, monitor, and recover many constrained nodes that are intermittently connected and often unreachable by a technician.
The decision is not "Kubernetes everywhere." A tiny sensor may only need signed firmware and a rollback slot.
Advanced autonomy is a reconciliation problem.

Major section

2. Making the Cloud Registry a Runtime Dependency · 3. Using One Merge Rule for Every State Class

A registry is useful for operations, inventory, and governance.

A local device should still have a way to reconnect to a valid local service during cloud isolation.
Last-write-wins, cloud-wins, fog-wins, manual review, and append-only records each fit different semantics.
A single universal rule eventually loses important information.

Major section

Summary · Key Takeaway

Advanced edge-fog-cloud design is about production contracts, not extra layers.

Discovery needs local operation, cached valid paths, and operational visibility.
Fog nodes are sensitive trust boundaries when they decrypt, aggregate, cache, or decide.
Orchestration must include fallback behavior for outages, overload, and version drift.
Observability must show local health and recovery status, not only cloud dashboard state.

Deck summary

Key takeaways

One shop loses its outside link during the change.

Discovery is a dependency: Devices need a local way to find services, a remembered last-known-good path, and an operational registry that does not become a runtime single point of failure.
The closing label, Contracts make failures recoverable, connects the map to the chapter's production claim: each concern needs an owner and a failure contract, not simply a tier name.
Network partitions are normal in distributed IoT.
A safety command path, credential update, or audit ledger usually needs stronger authority than an opportunistic swarm can provide.

Retrieval practice

Recall check 1 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q1A multi-site pilot has conflicting local and cloud settings after an outage. What must its operating decision record say?

AName dashboard appearance alone as proof that conflicting settings reconciled.

BName gateway vendors alone as the authority for local and cloud settings.

CName the setting owner, version reconciliation rule and proof of recovery.

DName the site count alone as the rule for reconciling setting versions.

Show answer

Answer: C State authority, catch-up, and recovery evidence make the split operable.

Retrieval practice

Recall check 2 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q2A device can reach its local network, but the local DNS server is unavailable. The fog gateway is still healthy. Which discovery design is most resilient?

AUse a validated cached local fallback and report its use after recovery.

BStop local operation until both cloud registry and local DNS are reachable.

CConnect to any gateway-port responder during failover because port availability establishes gateway identity.

DDelete cached gateway addresses on DNS failure and restart discovery cold.

Show answer

Answer: A A resilient device has more than one local path and reports fallback use so operators can fix the discovery dependency later.

Retrieval practice

Recall check 3 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q3A machine calibration value is measured on the physical equipment by a technician while the site is offline. Which authority model usually fits best?

AFog or site authority for the measured value, with cloud history afterward

BGive cloud calibration authority for fleet consistency because offline technician measurements cannot represent the fleet.

CAppend-only telemetry history as the active calibration value authority

DNo named authority because timestamps alone settle calibration conflicts

Show answer

Answer: A Calibration is tied to the physical machine.

Retrieval practice

Recall check 4 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q4A site-level analytics workload normally runs on a fog gateway. During WAN outage, the cloud dashboard is unavailable but local control must continue. What should the orchestration plan specify?

AStop local analytics because the cloud dashboard cannot receive results.

BMove all fog workloads to cloud during a WAN outage because cloud routing remains reachable through the backup path.

CDelete queued summaries during the outage so no backlog appears afterward.

DKeep local analytics running and queue summaries until cloud service returns.

Show answer

Answer: D The fallback plan preserves local operation, protects cloud-bound data for later replay, and gives operators visibility while the cloud view is stale.

Retrieval practice

Recall check 5 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q5A KubeEdge-managed edge node loses its connection to the cloud control plane for an hour. What should happen?

ARun under cached local authority, then reconcile when the cloud returns.

BStop all local workloads until cloud control resumes after the partition.

CErase cached state and redownload every workload after reconnection.

DMove site workloads to cloud while the edge node waits through outage.

Show answer

Answer: A Edge autonomy treats disconnection as normal: operate within cached authority, retain evidence, and reconcile when the control plane returns.

Retrieval practice

Recall check 6 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q6Complete the classifier that assigns an authority model to different state classes:

Aif state_class in {'fleet_policy', 'access_rule'}:

Bif state_class == 'temperature_sample':

Cif state_class is None:

Dif state_class in {'edge', 'cloud'}:

Show answer

Answer: A Fleet policy and access rules usually need cloud authority, physical calibration and site queues often need fog authority, and telemetry or audit events should be append-only with ordering and deduplication.

Print reference

Answers 1 of 2

Answer key.

C · State authority, catch-up, and recovery evidence make the split operable.
A · A resilient device has more than one local path and reports fallback use so operators can fix the discovery dependency later.
A · Calibration is tied to the physical machine.
D · The fallback plan preserves local operation, protects cloud-bound data for later replay, and gives operators visibility while the cloud view is stale.

Print reference

Answers 2 of 2

Answer key.

A · Edge autonomy treats disconnection as normal: operate within cached authority, retain evidence, and reconcile when the control plane returns.
A · Fleet policy and access rules usually need cloud authority, physical calibration and site queues often need fog authority, and telemetry or audit events should be append-only with ordering and deduplication.