14  Edge, Fog, and Cloud: Introduction

In 60 Seconds

The edge-fog-cloud three-layer architecture distributes IoT processing by latency needs: edge (under 50 ms, on-device filtering), fog (50-500 ms, regional aggregation on gateways), and cloud (500+ ms, global analytics and ML training). The “50-500-5000” rule guides placement: autonomous vehicle braking needs edge (5 ms), factory anomaly detection uses fog (100 ms), and fleet-wide trend analysis goes to cloud (5,000 ms is fine). Misplacing workloads – like routing safety alerts through the cloud – is the number one architecture anti-pattern, causing 200+ ms delays that can endanger lives.

Key Concepts

• Edge Computing: Processing data on or near the device generating it, achieving 1-10ms latency without WAN dependency
• Fog Computing: Intermediate processing tier between edge devices and cloud, deployed at local gateways or area servers
• Cloud Computing: Centralized data center providing elastic storage, compute, and managed services with 100ms+ latency for IoT applications
• Latency Hierarchy: Response time increases from edge (1-10ms) to fog (10-100ms) to cloud (100-500ms), determining which tier handles time-critical operations
• Offload Decision: Criteria (latency requirement, data volume, privacy constraint, connectivity reliability) used to assign workloads to appropriate tiers
• Hybrid Architecture: System design combining all three tiers; critical decisions at edge, coordination at fog, analytics and storage at cloud
• Data Gravity: Tendency for processing to migrate toward where data is stored; at scale, transmitting data to compute becomes more expensive than moving compute to data
• Cloud Egress Cost: Fee charged by cloud providers for data transferred out of their network, making large-volume IoT telemetry expensive at $0.08-$0.15/GB

14.1 Learning Objectives

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

• Explain the Three-Layer Architecture: Describe the roles of Edge, Fog, and Cloud nodes in IoT systems and justify why each tier exists
• Evaluate Processing Trade-offs: Compare edge, fog, and cloud processing for different use cases and assess which tier best fits a given scenario
• Apply the 50-500-5000 Rule: Use latency requirements to select appropriate processing tiers for real-world IoT deployments
• Calculate Bandwidth Savings: Estimate cost reductions from edge/fog data filtering versus cloud-only architectures using concrete metrics
• Diagnose Architecture Anti-Patterns: Identify common mistakes in tier selection and propose corrective design changes

The Challenge: Cloud Latency vs Local Limitations

The Problem: Pure cloud architecture fails for many IoT applications:

Challenge	Cloud-Only Impact	Real-World Consequence
Latency	100-500ms round-trip	Autonomous vehicles need <10ms for collision avoidance
Bandwidth	Raw sensor data is expensive	1,000 cameras at 1080p = 25 Gbps upload (>$50K/month)
Reliability	Internet outages halt operations	Factory safety systems cannot depend on external connectivity
Privacy	All data leaves premises	Healthcare and financial data may violate regulations

Why This Is Hard:

• Cloud offers unlimited compute power, but is geographically distant (50-200ms network latency)
• Edge devices are physically close, but have limited CPU/memory (cannot run complex ML models)
• Different applications have vastly different requirements: a smart thermostat can tolerate 5-second delays; an industrial robot cannot tolerate 50ms
• Data gravity makes moving data expensive: it costs less to move computation to data than data to computation

The Solution: An Edge-Fog-Cloud continuum where processing happens at the optimal layer based on latency, bandwidth, privacy, and reliability requirements.

Putting Numbers to It

At 60 km/h (16.7 m/s), network latency directly translates to travel distance: \(d = v \times t\). Worked example: Edge processing with 15ms latency means the car travels \(16.7 \text{ m/s} \times 0.015\text{s} = 0.25\text{m}\) (25 cm) before braking. Cloud processing with 300ms latency means \(16.7 \text{ m/s} \times 0.300\text{s} = 5.0\text{m}\) traveled – a 4.75-meter difference that determines collision vs. safe stop.

Related Chapters, Products, and Tools

• Reference Models & Enablers: For the big-picture language used here, see IoT Reference Models and Architectural Enablers.
• Edge & Data Analytics: To explore concrete edge patterns and analytics pipelines, read Edge Compute Patterns and Edge Comprehensive Review.
• Interactive Tools: Use the Compute Placement Calculator to practice tier selection decisions.
• Simulation Playground: Use the Simulation Playground to experiment with the Edge vs Cloud Latency Explorer.

14.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Overview of IoT: Basic IoT concepts and definitions
• Networking Basics: Understanding of IP networks, protocols, and data transmission

14.3 Getting Started (For Beginners)

New to Edge, Fog, and Cloud? Start Here!

This section is designed for beginners. If you’re already familiar with distributed computing architectures, feel free to skip to the Architecture chapter.

14.3.1 What Are Edge, Fog, and Cloud? (Simple Explanation)

Analogy: Think of a restaurant kitchen to understand where data gets processed.

Location	Restaurant Analogy	IoT Equivalent
Edge	Your table (where you taste the food)	Sensor/device (where data is collected)
Fog	Prep station (quick prep nearby)	Local gateway (fast, nearby processing)
Cloud	Main kitchen (full cooking capabilities)	Data center (powerful, remote processing)

14.3.2 Why Three Layers Instead of One?

The Problem: Imagine if every order had to go to the main kitchen, even just to add salt:

• Too slow: Long wait for simple requests
• Kitchen overloaded: Main chefs handling trivial tasks
• Expensive: Using premium resources for basic work

The Solution: Process things at the right place:

Flowchart diagram

Figure 14.1: Three-tier IoT architecture illustrated with restaurant kitchen analogy: Edge layer (navy blue box) for immediate adjustments at the table, Fog layer (teal box) for local preparation work nearby, and Cloud layer (orange box) for complex cooking in the full kitchen.

Latency decision tree for edge-fog-cloud tier selection

Figure 14.2: Latency-Driven Decision Tree: The key insight is that latency is the primary driver of tier selection: safety-critical systems (<50ms) must use edge; time-sensitive applications (50-500ms) benefit from fog; only delay-tolerant analytics should rely on cloud.

14.3.3 Real-World Examples

Example 1: Self-Driving Car

• Edge: Camera sees stop sign (must react in milliseconds!)
• Fog: Car computer processes image locally (can’t wait for cloud)
• Cloud: Uploads driving data overnight for AI training

Example 2: Smart Factory

Tier	Function	Action
Edge	Vibration sensor	Detects anomaly
Fog	Local controller	Shuts down motor immediately (safety!)
Cloud	Analytics engine	Analyzes patterns across 1000 factories to predict failures

Example 3: Fitness Tracker

Tier	Function	Action
Edge	Accelerometer	Counts your steps
Fog	Phone app	Calculates daily totals
Cloud	Analytics platform	Compares activity to millions of users

14.3.4 How Data Flows Through the Three Tiers

Understanding the three-tier architecture means understanding how data moves, gets filtered, and is transformed at each stage. The following diagram illustrates a typical data pipeline from sensor to cloud.

Key observation: Data volume drops by 99.9% from sensors to cloud. The 1,000 sensors producing 100 readings/second (100,000 data points/sec) are reduced to roughly one summary report per hour reaching the cloud. This is the fundamental economic argument for edge and fog computing.

14.3.5 Architecture Comparison: What Runs Where

The following diagram shows how data processing responsibilities are distributed across the three tiers, from physical proximity to the sensors (bottom) to global scale (top).

14.3.6 Key Insight: It’s About Trade-offs

Factor	Edge	Fog	Cloud
Speed	Fastest (milliseconds)	Fast (seconds)	Slower (seconds-minutes)
Power	Limited (battery)	Medium	Unlimited
Storage	Tiny (KB-MB)	Small (GB)	Huge (TB-PB)
Intelligence	Simple rules	Basic ML	Advanced AI
Cost	Cheapest per device	Medium	Cheapest at scale
Internet needed?	No	Maybe	Yes

14.3.7 Worked Example: Bandwidth Cost Calculation

Worked Example: Why Edge Filtering Saves Money

Scenario: A warehouse has 200 temperature sensors, each sampling at 1 Hz (once per second). Each reading is 64 bytes (timestamp + sensor ID + value + metadata).

Step 1: Calculate raw data volume

• Data per sensor per second: 64 bytes
• Total sensors: 200
• Data per second: 200 x 64 = 12,800 bytes/sec = 12.5 KB/sec
• Data per day: 12,800 x 86,400 = 1.05 GB/day
• Data per month: 1.05 x 30 = 31.5 GB/month

Step 2: Calculate cloud-only cost

Using typical cloud IoT pricing:

Cost Component	Rate	Monthly Cost
Data ingestion	$0.08/GB	$2.52
Data transfer (in)	$0.00/GB	$0.00
Storage (hot)	$0.023/GB	$0.72
Time-series queries	$0.005/million	~$12.96
Total cloud-only		~$16.20/month

Step 3: Apply edge filtering

In practice, warehouse temperatures are stable 95% of the time. Edge filtering sends only:

• Changes > 0.5 degrees from last reading (~5% of samples)
• Threshold alerts for out-of-range values (~0.1%)
• Hourly summaries (200 sensors x 24 hours = 4,800 records/day)

Filtered data volume: ~1.6 GB/month (95% reduction)

Cost Component	Rate	Monthly Cost
Data ingestion	$0.08/GB	$0.13
Storage (hot)	$0.023/GB	$0.04
Time-series queries	$0.005/million	~$0.65
Edge hardware (amortized)	ESP32 x 200 = $1,000 / 36 mo	$27.78
Total with edge		~$28.60/month

Wait – edge is more expensive? Not when you factor in scale. At 200 sensors, the hardware cost dominates. But at 2,000 sensors:

Architecture	Monthly Cost (2,000 sensors)
Cloud-only	$162/month (scales linearly)
Edge + Cloud	$48/month (hardware amortized, data costs flat)

Key insight: Edge filtering provides 70% cost savings at scale because cloud costs scale linearly with data volume, while edge hardware is a one-time investment.

Putting Numbers to It

Bandwidth cost scales with sensor count: \(C_{monthly} = N_{sensors} \times rate \times bytes \times 2592000\text{s} \times price/GB\). Worked example: 2,000 sensors at 1 Hz × 64 bytes = 128 KB/s = 332.9 GB/month raw. At $0.08/GB ingestion: $26.63/month. With 95% edge filtering: 16.6 GB/month = $1.33/month. Hardware cost ($200 edge device/36 months = $5.56/month) plus bandwidth ($1.33) = $6.89/month total, saving $19.74/month per site. Break-even: 36-month amortization matches typical hardware lifecycle.

14.3.8 Interactive: Edge Filtering Cost Calculator

Use this calculator to explore how edge filtering affects bandwidth costs at different scales. Adjust the parameters to see when edge-first architecture becomes more cost-effective than cloud-only.

viewof efcSensors = Inputs.range([10, 10000], {value: 200, step: 10, label: "Number of sensors"})
viewof efcSamplingHz = Inputs.range([1, 100], {value: 1, step: 1, label: "Sampling rate (Hz)"})
viewof efcBytesPerReading = Inputs.range([8, 256], {value: 64, step: 8, label: "Bytes per reading"})
viewof efcCloudIngestionCost = Inputs.range([0.01, 0.50], {value: 0.08, step: 0.01, label: "Cloud ingestion cost ($/GB)"})
viewof efcEdgeFilterPct = Inputs.range([50, 99.9], {value: 95, step: 0.5, label: "Edge filtering efficiency (%)"})
viewof efcEdgeHardwareCost = Inputs.range([100, 10000], {value: 1000, step: 100, label: "Total edge hardware cost ($)"})
viewof efcAmortizationMonths = Inputs.range([12, 60], {value: 36, step: 6, label: "Hardware amortization (months)"})

efcResults = {
  const rawBytesPerSec = efcSensors * efcSamplingHz * efcBytesPerReading;
  const rawGBPerMonth = (rawBytesPerSec * 86400 * 30) / 1e9;
  const filteredGBPerMonth = rawGBPerMonth * (1 - efcEdgeFilterPct / 100);
  const cloudOnlyCost = rawGBPerMonth * efcCloudIngestionCost;
  const filteredCloudCost = filteredGBPerMonth * efcCloudIngestionCost;
  const monthlyHardwareCost = efcEdgeHardwareCost / efcAmortizationMonths;
  const edgePlusCloudCost = filteredCloudCost + monthlyHardwareCost;
  const monthlySavings = cloudOnlyCost - edgePlusCloudCost;
  const savingsPct = cloudOnlyCost > 0 ? (monthlySavings / cloudOnlyCost) * 100 : 0;
  const breakEvenSensors = efcCloudIngestionCost > 0 ? Math.ceil((efcEdgeHardwareCost / efcAmortizationMonths) / ((rawGBPerMonth / efcSensors) * efcCloudIngestionCost * (efcEdgeFilterPct / 100))) : 0;

  const savingsColor = monthlySavings > 0 ? "#16A085" : "#E74C3C";
  const verdictText = monthlySavings > 0
    ? `Edge filtering saves <strong>$${monthlySavings.toFixed(2)}/month</strong> (${savingsPct.toFixed(1)}% reduction)`
    : `Cloud-only is cheaper by <strong>$${Math.abs(monthlySavings).toFixed(2)}/month</strong> — scale up sensors or increase filtering to break even`;

  return html`
    <div style="background: linear-gradient(135deg, #f8f9fa, #e9ecef); padding: 1.5rem; border-radius: 8px; margin: 1rem 0;">
      <h4 style="color: #2C3E50; margin-top: 0;">Cost Comparison Results</h4>
      <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 1rem; margin-bottom: 1rem;">
        <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid #E67E22;">
          <div style="font-size: 0.85rem; color: #7F8C8D;">Raw Data Volume</div>
          <div style="font-size: 1.3rem; font-weight: bold; color: #E67E22;">${rawGBPerMonth.toFixed(1)} GB/month</div>
          <div style="font-size: 0.75rem; color: #7F8C8D;">${(rawBytesPerSec / 1000).toFixed(1)} KB/sec</div>
        </div>
        <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid #E74C3C;">
          <div style="font-size: 0.85rem; color: #7F8C8D;">Cloud-Only Cost</div>
          <div style="font-size: 1.3rem; font-weight: bold; color: #E74C3C;">$${cloudOnlyCost.toFixed(2)}/month</div>
          <div style="font-size: 0.75rem; color: #7F8C8D;">Ingestion only</div>
        </div>
        <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid #3498DB;">
          <div style="font-size: 0.85rem; color: #7F8C8D;">Edge + Cloud Cost</div>
          <div style="font-size: 1.3rem; font-weight: bold; color: #3498DB;">$${edgePlusCloudCost.toFixed(2)}/month</div>
          <div style="font-size: 0.75rem; color: #7F8C8D;">$${filteredCloudCost.toFixed(2)} cloud + $${monthlyHardwareCost.toFixed(2)} hardware</div>
        </div>
        <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${savingsColor};">
          <div style="font-size: 0.85rem; color: #7F8C8D;">Monthly Savings</div>
          <div style="font-size: 1.3rem; font-weight: bold; color: ${savingsColor};">$${monthlySavings.toFixed(2)}</div>
          <div style="font-size: 0.75rem; color: #7F8C8D;">${savingsPct.toFixed(1)}% ${monthlySavings > 0 ? "saved" : "more expensive"}</div>
        </div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid #2C3E50;">
        <strong style="color: #2C3E50;">Verdict:</strong> ${verdictText}
      </div>
      <div style="margin-top: 0.75rem; font-size: 0.8rem; color: #7F8C8D;">
        <strong>Try this:</strong> Set sensors to 200 (worked example default), then increase to 2,000 to see how edge filtering becomes increasingly cost-effective at scale.
      </div>
    </div>`;
}

14.3.9 Common Misconceptions

Common Mistakes in Edge-Fog-Cloud Architecture

Misconception 1: “Edge computing replaces the cloud”

• Reality: Edge complements the cloud. Edge handles real-time decisions; cloud handles long-term analytics, ML training, and global coordination. Removing the cloud means losing historical insights and cross-site comparisons.

Misconception 2: “Fog and edge are the same thing”

• Reality: Edge runs ON the sensor/device (ESP32, Raspberry Pi). Fog runs on NEARBY infrastructure (local server, gateway, router). The distinction matters: edge has milliwatt power budgets and KB of RAM; fog nodes have wall power and GB of RAM.

Misconception 3: “Lower latency is always better”

• Reality: Over-engineering for latency wastes money. A daily energy report does not need edge processing. Sending every reading through an edge ML pipeline when a simple cloud batch job would suffice increases hardware costs and system complexity for zero benefit.

Misconception 4: “Just put everything at the edge – it’s cheaper”

• Reality: Edge devices have severe compute limitations. An ESP32 (240 MHz, 520 KB SRAM) cannot run a transformer model or join data across 10,000 sensors. Complex analytics MUST happen in the cloud or fog. The worked example above shows that at small scale, edge hardware costs can exceed cloud costs.

Misconception 5: “The three tiers are rigid categories”

• Reality: Edge-Fog-Cloud is a continuum, not three discrete buckets. A Raspberry Pi can be “edge” in one deployment and “fog” in another. A 5G base station with MEC (Multi-access Edge Computing) blurs fog and cloud. Choose based on latency, bandwidth, and privacy requirements, not labels.

14.3.10 Self-Check Questions

Before continuing, make sure you understand:

1. Why can’t everything just go to the cloud? (Answer: Latency – some applications need sub-50ms response. Bandwidth – raw sensor data transfer is expensive. Reliability – internet outages cannot halt safety-critical systems.)
2. What’s the main job of fog nodes? (Answer: Local aggregation, protocol translation, and regional processing. Fog reduces data volume before cloud and provides faster response than cloud for time-sensitive tasks.)
3. When would you NEED edge processing? (Answer: Safety-critical applications requiring <50ms response, offline operation when internet is unavailable, and privacy-sensitive data that must not leave the premises.)
4. How much bandwidth can edge filtering save? (Answer: Typically 90-99% for sensor data, because most readings are redundant. Only changes, anomalies, and periodic summaries need to reach fog/cloud.)
5. When is cloud-only architecture still the right choice? (Answer: When latency tolerance is high (>5 seconds), data volume is low, internet connectivity is reliable, and the application needs global-scale analytics or ML training.)

For Kids: Meet the Sensor Squad!

Edge, Fog, and Cloud computing is like having helpers at different distances - some right next to you for quick tasks, and others far away for big thinking jobs!

14.3.11 The Sensor Squad Adventure: The Great Temperature Race

It was the hottest summer day ever, and the Sensor Squad was on an important mission at the ice cream factory! Sammy the Sensor was watching the freezer temperature, and if it got too warm, all the ice cream would melt into a gooey mess!

“Oh no!” beeped Sammy suddenly. “The temperature is rising fast! We need to turn on the backup cooler RIGHT NOW!” But here was the problem: Should Sammy ask the faraway Cloud Computer (who was super smart but lived miles away), the nearby Fog Computer (who was pretty smart and lived in the factory office), or should Max the Microcontroller (who was right there in the freezer) make the decision?

“There’s no time to wait!” shouted Lila the LED, flashing red warning lights. “By the time we send a message to the Cloud and wait for an answer, the ice cream will be soup!” Max the Microcontroller jumped into action. “I’ll handle this at the EDGE - that means right here, right now!” He instantly switched on the backup cooler in just 10 milliseconds - faster than you can blink! Later, Bella the Battery suggested they send a summary to the Fog Computer to keep a log, and at night when things were calm, they uploaded all the day’s data to the Cloud for the factory owner to review.

14.3.12 Key Words for Kids

Word	What It Means
Edge	Computing that happens right at the sensor or device - like making a decision in your own brain
Fog	Computing that happens nearby but not right at the sensor - like asking a friend in the same room
Cloud	Super powerful computers far away that can do amazing things - but messages take longer to get there
Latency	How long it takes for a message to travel somewhere and get an answer back

14.3.13 Try This at Home!

The Helper Distance Game: Play this game with family or friends! You are the “sensor” and you need to make decisions. Have three helpers: one standing right next to you (Edge), one across the room (Fog), and one in another room (Cloud). When you say “EMERGENCY!” everyone races to give you a thumbs up. The closest helper (Edge) will always respond fastest! Then try asking a hard math question - the far-away helper (Cloud) might be better at that even though they’re slower.

Key Takeaway

In one sentence: The Edge-Fog-Cloud architecture distributes IoT processing across three tiers based on latency, bandwidth, and reliability requirements – edge for millisecond safety decisions, fog for local aggregation and protocol translation, cloud for long-term analytics.

Remember this: Use the “50-500-5000” rule: If you need response under 50ms, process at the edge device. If under 500ms, fog gateways work. If 5000ms (5 seconds) is acceptable, cloud processing is viable.

The economic argument: Edge filtering typically reduces data volume by 90-99%, cutting cloud costs proportionally. At scale (thousands of sensors), edge-first architectures save 50-80% compared to cloud-only.

Historical Context: How Edge Computing Emerged

Centralized Era (1960s-1990s): Computing began with mainframes where all processing happened in central facilities. Data centers emerged in the 1990s, consolidating servers for efficiency.

Cloud Revolution (2006-2015): Amazon Web Services launched in 2006, followed by Azure (2010) and Google Cloud (2012). Cloud computing offered elastic, pay-per-use compute that scaled infinitely. But geography imposed hard limits: network latency remained 50-200ms to the nearest region.

IoT Challenge (2010-2015): The explosion of connected devices revealed cloud’s limitations. Autonomous vehicles generate 1-4 TB/hour and need <10ms collision avoidance - cloud’s 100-500ms round-trip is 10-50x too slow. Smart factories require <50ms for safety shutdowns.

Fog Computing (2015-2018): Cisco coined “fog computing” in 2015, proposing hierarchical processing between edge and cloud. Key insight: not all data needs to reach the cloud - process time-critical decisions locally.

Edge AI (2018-present): Google’s Edge TPU (2018), NVIDIA Jetson, and TensorFlow Lite Micro brought ML inference to edge devices. Edge went from “dumb sensors” to “intelligent nodes.”

Why This Matters: A 2024 study found 75% of enterprise data will be processed outside traditional data centers by 2025, up from 10% in 2018.

Minimum Viable Understanding: Latency-Driven Architecture

Core Concept: Network latency to the cloud (100-500ms round-trip) is a physical constraint that cannot be optimized away – safety-critical decisions must happen locally.

Why It Matters: At 60 mph, a vehicle travels 2.7 meters during a 100ms delay. Industrial equipment can be destroyed in 50ms. Physics dictates that time-critical processing must be edge-local.

Key Takeaway: Use the “50-500-5000” rule: Match your architecture tier to your most demanding latency requirement.

Quick Decision Framework:

Your Requirement	Choose This Tier	Example
Response < 50ms	Edge	Collision avoidance, emergency shutoff
Response 50-500ms	Fog	Video analytics, local dashboards
Response > 5 sec	Cloud	Monthly reports, ML model training
Must work offline	Edge	Remote agriculture, underground mining
Cross-site analytics	Cloud	Fleet comparison, global trends

Interactive: Edge-Fog-Cloud Data Flow Animation

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

🏷️ Label the Diagram

💻 Code Challenge

14.4 Summary

This chapter introduced the fundamental concepts of Edge-Fog-Cloud architecture:

The Core Problem and Solution:

• The Problem: Cloud latency (100-500ms) is too slow for safety-critical and real-time IoT applications, bandwidth costs scale linearly with raw data, and internet outages can halt safety systems
• The Solution: Distribute processing across three tiers based on latency, bandwidth, privacy, and reliability requirements

The Three Tiers:

• Edge (sensors, MCUs): Millisecond responses, offline operation, threshold-based filtering. Processes data where it is generated.
• Fog (gateways, SBCs): Local aggregation, protocol translation, regional ML inference. Bridges edge devices and cloud.
• Cloud (data centers): Long-term analytics, ML model training, global coordination, historical storage. Handles workloads that need scale.

Key Decision Rules:

• The 50-500-5000 Rule: Under 50ms = Edge, Under 500ms = Fog, Over 5000ms = Cloud
• Data gravity: Move computation to data, not data to computation
• Bandwidth economics: Edge filtering reduces data volume by 90-99%, saving 50-80% at scale
• The continuum: Tiers are not rigid – the same hardware can serve as edge or fog depending on context

Common Pitfalls to Avoid:

• Do not assume edge replaces cloud (they are complementary)
• Do not over-engineer for latency when the application is delay-tolerant
• Do not confuse edge and fog (edge = on the device; fog = nearby infrastructure)

14.5 Knowledge Check

Quiz: Edge, Fog, and Cloud: Introduction

14.6 What’s Next

Topic	Chapter	Description
Interactive Tools	Edge-Fog-Cloud Interactive Tools	Practice with the Compute Placement Calculator and scenario-based game
Architecture	Edge-Fog-Cloud Architecture	Detailed analysis of the three-layer architecture and MGC terminology
Devices & Integration	Edge-Fog-Cloud Devices and Integration	Device selection criteria and integration patterns for each tier