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.
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.
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.
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 5
Edge Eddie says: answer from memory, then check your reasoning.
Q1A proof-of-concept works at one site. Before expanding to many sites, what should the architecture team define first?
Show answer
Answer: C Multi-site production failures usually come from implicit contracts: devices cannot find services, state conflicts are undefined, credentials are overbroad, fallback behavior is missing, or local health signals are invisible.
Retrieval practice
Recall check 2 of 5
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?
Show answer
Answer: B 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 5
Edge Eddie says: answer from memory, then check your reasoning.
Q3A fog node decrypts device messages so it can aggregate, filter, and apply local policy. What security implication follows?
Show answer
Answer: B If the fog node reads payloads to do useful work, it must be treated as a sensitive processing point with its own controls.
Retrieval practice
Recall check 4 of 5
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?
Show answer
Answer: C 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 5
Edge Eddie says: answer from memory, then check your reasoning.
Q5Place each production concern where it lives so you can contain failures across edge, fog, and cloud boundaries.
Show answer
Answer: A Separate discovery, state coordination, and protected recovery so you can locate participants, resolve truth, and diagnose failures without blurring trust boundaries.
Q6Complete the classifier that assigns an authority model to different state classes:
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 · Multi-site production failures usually come from implicit contracts: devices cannot find services, state conflicts are undefined, credentials are overbroad, fallback behavior is missing, or local health signals are invisible.
- B · A resilient device has more than one local path and reports fallback use so operators can fix the discovery dependency later.
- B · If the fog node reads payloads to do useful work, it must be treated as a sensitive processing point with its own controls.
Print reference
Answers 2 of 2
Answer key.
- C · The fallback plan preserves local operation, protects cloud-bound data for later replay, and gives operators visibility while the cloud view is stale.
- A · Separate discovery, state coordination, and protected recovery so you can locate participants, resolve truth, and diagnose failures without blurring trust boundaries.
- 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.