34  Fog Architecture and Applications

34.1 Learning Objectives

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

  • Design three-tier fog architectures that partition processing across edge, fog, and cloud layers for latency-critical IoT deployments
  • Compare fog, cloudlet, and cloud-only approaches using quantitative metrics including latency (5-50ms vs. 100-500ms), bandwidth reduction (90-99%), and cost trade-offs
  • Evaluate when fog computing is architecturally justified versus over-engineered, using a decision framework based on response time, connectivity, data volume, and privacy requirements
  • Analyze real-world fog deployment case studies (Barcelona Smart City, BP Pipeline Monitoring) to extract reusable architectural patterns
  • Calculate bandwidth savings from fog-based data filtering and aggregation for sensor networks ranging from 100 to 10,000 nodes
  • Implement fault-tolerant fog designs that avoid single points of failure, sync storms, and clock skew across distributed fog nodes
In 60 Seconds

Fog computing adds a middle tier between IoT sensors and the cloud, cutting latency from 200ms to 10-50ms and reducing bandwidth consumption by 90-99%. A three-tier architecture assigns real-time safety decisions to edge nodes, local analytics and protocol translation to fog gateways, and historical storage and global ML to cloud. Applications like autonomous vehicles, smart factories, and precision agriculture depend on fog to meet response times physically impossible via cloud alone.

Key Concepts
  • Three-Tier Fog Architecture: Hierarchical design where edge (1-10ms), fog (10-100ms), and cloud (100ms+) each handle tasks matched to their latency and compute characteristics
  • Fog Application Domain: Category of IoT deployment (industrial, healthcare, transportation, agriculture) defining the specific latency, reliability, and privacy requirements fog must satisfy
  • Service Chaining: Fog capability linking multiple processing functions (filtering → aggregation → anomaly detection → alerting) as a pipeline for each incoming data stream
  • Cloudlet: Resource-rich mini-data-center at the campus edge enabling compute offload from mobile/IoT devices at LAN latency without WAN traversal
  • Fog Orchestration Platform: Software layer (KubeEdge, OpenYurt, AWS Greengrass) managing workload placement and lifecycle across distributed fog nodes
  • Context Aggregation: Combining readings from nearby sensors at a fog node to produce higher-level situational awareness (e.g., vehicle speed + road condition + weather = hazard score)
  • Multi-Tenancy: Fog node capability hosting isolated workloads for multiple applications or customers using containerization or hypervisor-based partitioning
  • Southbound/Northbound APIs: Standard interfaces connecting fog to edge devices (southbound: Modbus, OPC-UA, MQTT) and to cloud (northbound: REST, AMQP, WebSocket)
Minimum Viable Understanding
  • Fog is an intermediate processing layer: sits between edge sensors and the cloud, reducing bandwidth by 90-99% while cutting latency from 100-500ms down to 5-50ms
  • Three-tier data flow: edge devices collect raw data, fog nodes filter/aggregate/decide locally, cloud handles historical analytics and AI model training
  • Use fog when: response time must be <100ms, connectivity is unreliable (<99% uptime), data volume exceeds 1 MB/sec per site, or sensitive data must stay on-premises

Meet the Sensor Squad! Today they are on a mission inside a smart toy factory with three floors – just like the three layers of fog computing!

Sammy (sound sensor) is on the factory floor listening for unusual machine noises. Lila (light sensor) monitors the conveyor belt, watching for jams when products block her beam. Max (motion sensor) tracks whether workers are near dangerous equipment. Bella (button sensor) sits on the emergency panel, ready if anyone presses the big red stop button.

The Problem:

One morning, Sammy hears Machine #5 grinding louder than normal – a sign it is overheating! He needs to alert someone fast.

Without Fog (the slow way):

Sammy sends his warning all the way up to the Cloud Castle in the sky:

  • 0ms: Sammy detects the grinding noise
  • 100ms: The message travels across the internet to the distant Cloud Castle
  • 150ms: The Cloud Castle thinks about what to do
  • 250ms: The Cloud Castle sends back “STOP THE MACHINE!”
  • TOTAL: 250ms – by then, Machine #5 could already be damaged!

With Fog (the fast way):

Sammy sends his warning to the Fog Gateway on the second floor, right above the factory:

  • 0ms: Sammy detects the grinding noise
  • 5ms: The message reaches the Fog Gateway (it is close by!)
  • 10ms: The Fog Gateway immediately says “STOP THE MACHINE!”
  • TOTAL: 10ms – Machine #5 stops safely!

Meanwhile, Lila confirms the conveyor has halted. Max checks that no workers are near. Bella’s emergency panel light turns on. The whole squad works together locally.

The Fog Gateway then sends a calm summary up to the Cloud Castle: “We had a small incident. Already handled. Here is the data for your records.”

Layer Who Job Speed
Edge Sammy, Lila, Max, Bella Collect data, simple alerts Instant
Fog Fog Gateway Quick decisions, filters data Very fast (5-50ms)
Cloud Cloud Castle Stores history, trains AI models Slower (100-500ms)

The Lesson: Just like you ask your teacher for help before calling the principal, IoT devices ask the nearby fog layer before bothering the distant cloud. Fog computing lets local helpers handle routine stuff quickly!

Think of fog computing as putting a “mini-cloud” right next to your devices.

You know how clouds are high in the sky? Well, “fog” is close to the ground. In computing, the “cloud” is a faraway data center, and “fog” is local processing that happens much closer to your sensors and devices.

The Problem Fog Solves:

Imagine you have a smart factory with 1,000 temperature sensors, each sending 10 readings per second. That’s 10,000 messages per second going to the cloud!

  • Without fog: All 10,000 messages travel to the cloud (expensive, slow, internet-dependent)
  • With fog: A local computer filters the data, only sending 1 message per minute (99.9% reduction!)

Real-world analogy: Fog computing is like having a manager at each department instead of having every employee report directly to the CEO. The manager handles routine decisions locally and only escalates important issues to headquarters.

When to Use Fog:

  • Real-time safety: Factory machines that need to stop in 5ms (not 200ms)
  • Bandwidth savings: When sending all data to cloud costs too much
  • Offline operation: When systems must work even if internet fails
  • Privacy: When sensitive data shouldn’t leave the local network

34.2 Overview

Fog computing extends cloud capabilities to the network edge, creating a distributed computing hierarchy that addresses latency, bandwidth, and reliability challenges in IoT deployments. This chapter series provides comprehensive coverage of fog architecture design, real-world applications, and deployment best practices.

Three-tier fog computing data flow diagram showing Edge Layer with 1000 sensors producing 10000 messages per second flowing into the Fog Layer gateway that filters aggregates and decides locally reducing traffic to 10 messages per second then forwarding summaries to the Cloud Layer for analytics and model training. Annotations show latency at each tier: under 1ms at edge, 5 to 50ms at fog, 100 to 500ms at cloud. Uses IEEE colors: orange for edge, teal for fog, navy for cloud.

Flowchart showing the four-chapter fog computing series: Chapter 1 Architecture (Three-Tier Design, Hardware Selection, Fog Node Capabilities) flows to Chapter 2 Applications (Smart City Cases, Industrial IoT, Worked Examples), then to Chapter 3 Cloudlets (VM Synthesis, Mobile Offloading, Decision Framework), and finally Chapter 4 Challenges (Failure Scenarios, Common Pitfalls, Deployment Checklist). Uses IEEE colors: navy background, teal for architecture, orange for applications, gray for cloudlets, and dark blue for challenges.

34.3 Chapter Organization

This topic has been organized into four focused chapters for easier navigation and learning:

34.3.1 Fog Architecture: Three-Tier Design and Hardware

Covers the foundational architecture of fog computing:

  • Three-Tier Architecture: Edge devices, fog nodes, and cloud data centers
  • Fog Node Capabilities: Computation, storage, networking, and security functions
  • Hardware Selection Guide: Choosing appropriate gateways from entry-level to high-performance
  • Beginner-Friendly Introduction: Sensor Squad story and simplified explanations

34.3.2 Fog Applications and Use Cases

Explores real-world fog computing deployments:

  • Industry Case Studies: Barcelona Smart City (Cisco), BP Pipeline Monitoring (AWS Greengrass)
  • Hierarchical Processing: Data flow across edge, fog, and cloud tiers
  • Operational Phases: Data collection, fog processing, cloud analytics, and action phases
  • Worked Examples: Bandwidth optimization, offline operation, load balancing, failure detection

34.3.3 Cloudlets: Datacenter in a Box

Examines cloudlet architecture for mobile-enhanced applications:

  • VM Synthesis: Rapid VM creation from compact overlays (40-80× smaller than full VMs)
  • Cloudlet vs. Cloud: Decision framework based on latency, privacy, connectivity, and data volume
  • Architecture Components: VNC Server, Launcher, KVM, Avahi, Infrastructure Server
  • Use Cases: Mobile AR, cognitive assistance, gaming, emergency response

34.3.4 Fog Challenges and Failure Scenarios

Addresses deployment challenges and lessons learned:

  • Technical Challenges: Resource management, programming complexity, security, orchestration
  • Failure Scenarios: Single gateway bottleneck, insufficient capacity, sync storms, clock skew
  • Common Pitfalls: ML model overload, lifecycle management, network variability, authentication dependencies
  • Deployment Checklist: Comprehensive verification before production

34.4 Prerequisites

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

34.5 Quick Reference

Chapter Focus Time Difficulty
Architecture Three-tier design, hardware selection ~25 min Intermediate
Applications Case studies, worked examples ~30 min Intermediate
Cloudlets VM synthesis, mobile offloading ~15 min Intermediate
Challenges Failures, pitfalls, checklists ~20 min Intermediate

34.6 Knowledge Check: Fog Computing Fundamentals

Before diving into the detailed chapters, test your understanding of the core fog computing concepts:

Common Pitfalls and Misconceptions

“Fog is just a small cloud”: Fog nodes are architecturally distinct from cloud instances. They provide location awareness, heterogeneous hardware support, and autonomous operation under intermittent connectivity. Deploying a cloud VM on-premises is not fog computing – it lacks offline decision logic, local data aggregation, and store-and-forward capabilities.

“All data should eventually reach the cloud”: In production fog deployments, 99%+ of raw sensor data is processed locally and never leaves the premises. Only aggregated summaries, anomalies, or model updates are forwarded. Designing systems that mirror all data to the cloud negates the bandwidth savings that justify fog in the first place.

“Fog computing eliminates the need for cloud”: Fog and cloud are complementary layers, not replacements. Cloud remains essential for historical analytics across months of data, AI/ML model training requiring GPU clusters, cross-site aggregation from multiple fog deployments, and long-term compliance archival. Removing cloud entirely leaves you without global visibility.

“Adding fog always improves performance”: Fog introduces additional complexity: firmware updates across distributed nodes, security patching of gateway operating systems, and orchestration overhead. For applications that tolerate 200ms+ latency with reliable (99.9%+ uptime) connectivity and low data volume (<100 KB/sec), a cloud-only architecture is simpler, cheaper, and easier to maintain.

“One fog gateway per site is sufficient”: A single gateway creates a critical single point of failure. When that gateway fails, all local sensors lose their processing layer and either go dark or flood the cloud with unfiltered data. Production fog deployments require at least N+1 redundancy, with automatic failover tested under load – not just documented in architecture diagrams.

34.7 Quick Decision Framework

Use this table to quickly determine if fog computing is appropriate for your application:

Requirement Fog Recommended Cloud Sufficient
Response Time <100ms needed >200ms acceptable
Connectivity Intermittent or unreliable Always available
Data Volume >1 MB/sec per site <100 KB/sec per site
Privacy Sensitive data must stay local Data can leave premises
Autonomy Must operate offline Cloud dependency acceptable
Cost Sensitivity High bandwidth costs Low bandwidth costs

Rule of Thumb: If you answer “Fog Recommended” to 3+ requirements, fog computing is likely beneficial.

Decision flowchart for choosing between fog and cloud computing. Starts with 'Does your application need less than 100ms response time?' If yes, use Fog. If no, asks 'Is connectivity reliable 99%+ uptime?' If no, use Fog. If yes, asks 'Is data volume over 1MB per second?' If yes, use Fog. If no, asks 'Must sensitive data stay local?' If yes, use Fog. If no, Cloud is sufficient. Uses IEEE colors: navy for start, teal for Fog outcome, orange for Cloud outcome.

Scenario: A shipping port terminal operates 50 gantry cranes, each with 20 sensors monitoring position, load weight, hydraulic pressure, and vibration. The port handles 1,200 container movements per hour across a 2km × 1km area with multiple operational zones.

Requirements:

  • Real-time collision detection between cranes (<50ms)
  • Load optimization across the terminal (zone-level decisions)
  • Historical analytics for predictive maintenance
  • Offline operation during network outages (2-3 times per month, 10-30 min each)

Architecture Decision:

Data Flow Analysis:

  1. Raw data volume per crane:
    • 20 sensors × 10 samples/sec × 100 bytes = 20 KB/sec
    • 50 cranes × 20 KB/sec = 1,000 KB/sec (1 MB/sec) total

Calculate the bandwidth savings and monthly cost reduction from deploying fog gateways at the port terminal instead of sending all raw sensor data to the cloud.

Cloud-Only Architecture (No Fog):

\[\text{Raw Data Rate} = 50 \text{ cranes} \times 20 \text{ sensors} \times 10 \text{ Hz} \times 100 \text{ bytes} = 1 \text{ MB/s}\]

\[\text{Monthly Data} = 1 \text{ MB/s} \times 86,400 \text{ s/day} \times 30 \text{ days} = 2,592 \text{ GB/month}\]

Assuming cellular backhaul at $10/GB:

\[\text{Monthly Bandwidth Cost} = 2,592 \text{ GB} \times \$10/\text{GB} = \$25,920\]

Fog Architecture (Zone Gateways):

Deploy 5 fog gateways (10 cranes per zone). Each gateway: - Aggregates local crane data (200 KB/s per gateway) - Runs collision detection locally - Sends only anomalies (1% of data) and hourly summaries to cloud

\[\text{Fog Filtering Ratio} = 99\% \text{ (only 1% forwarded)}\]

\[\text{Cloud-Bound Data} = 2,592 \text{ GB} \times 0.01 = 25.92 \text{ GB/month}\]

\[\text{New Monthly Cost} = 25.92 \text{ GB} \times \$10/\text{GB} = \$259.20\]

Savings:

\[\text{Annual Savings} = (\$25,920 - \$259.20) \times 12 = \$307,929\]

ROI Analysis:

  • 5 fog gateways @ $1,500 each = $7,500
  • Payback period: $7,500 / $25,660 monthly savings = 0.29 months (9 days)

The fog architecture achieves 99% bandwidth reduction and pays for itself in under 2 weeks.

  1. Edge layer (crane controllers):
    • Local safety checks: Emergency stop if load > rated capacity
    • Vibration monitoring: Flag excessive oscillation (>2Hz)
    • Position tracking: Update GPS coordinates
    • Processing: <5ms local threshold checks
    • Data forwarded to fog: Only position updates + anomalies = 50 KB/sec (95% reduction)
  2. Fog layer (zone gateways - 5 zones):
    • Collision detection: Calculate crane trajectories, detect potential collisions within 10 seconds
    • Load balancing: Optimize container distribution across cranes in the zone
    • Store-and-forward: Buffer data during network outages
    • Processing latency: 20-40ms for collision detection
    • Data forwarded to cloud: Aggregated zone statistics + collision events = 5 KB/sec (99.5% total reduction)
  3. Cloud layer:
    • Predictive maintenance: ML models on historical vibration data
    • Terminal-wide optimization: Balance workload across all 5 zones
    • Compliance reporting: Daily/monthly reports
    • Processing latency: 200-500ms (acceptable for analytics)

Bandwidth Cost Calculation (using standard cloud egress at $0.09/GB – for ports with wired backhaul; cellular backhaul at $10/GB yields much higher savings as shown in the “Putting Numbers to It” box above):

Without fog (cloud-only): - 1 MB/sec × 86,400 sec/day = 86.4 GB/day - At $0.09/GB egress: $7.78/day = $233/month

With fog architecture:

  • 5 KB/sec × 86,400 sec/day = 0.432 GB/day
  • At $0.09/GB: $0.04/day = $1.17/month

Monthly savings: $233 - $1.17 = $231.83/month

Fog gateway cost: 5 Intel NUC gateways × $800 = $4,000 one-time Breakeven time: $4,000 ÷ $231.83/month = 17.3 months

Offline Resilience:

During a 30-minute network outage: - Fog buffers: 5 KB/sec × 1,800 sec = 9 MB (easily handled by local storage) - Critical safety decisions: Collision detection continues operating without cloud - Crane operations: Unaffected - all real-time decisions made locally

Latency Verification:

Collision detection requirement: <50ms

  • Edge sensing: 5ms (sensor → controller)
  • Fog processing: 25ms (trajectory calculation + collision check for 10 cranes per zone)
  • Fog to edge command: 10ms (stop command to affected cranes)
  • Total: 40ms ✓ Meets requirement

Scalability:

If terminal expands to 100 cranes: - Raw data: 2 MB/sec (doubles) - Fog filtering: Still achieves 99%+ reduction - Cloud bandwidth: 10 KB/sec (still minimal) - Fog architecture scales linearly - add 1 gateway per 5 additional zones

Key Insight: This three-tier architecture achieves a 17-month ROI through bandwidth savings while meeting strict real-time requirements and providing offline resilience. The fog layer’s collision detection cannot be moved to edge (insufficient multi-crane visibility) or cloud (latency too high), demonstrating fog’s unique value proposition.

Use this framework to systematically evaluate whether fog computing is justified for your IoT deployment.

Criterion Cloud Sufficient Fog Beneficial Fog Mandatory Your Score
Latency Requirement >200ms acceptable 50-200ms needed <50ms required ___
Connectivity Reliability 99.9%+ uptime 95-99% uptime <95% or must operate offline ___
Data Volume (per site) <100 KB/sec 100 KB - 10 MB/sec >10 MB/sec ___
Privacy/Compliance Data can leave premises Prefer local processing Regulated data must stay local ___
Safety-Critical Decisions No real-time safety needs Safety with cloud fallback Autonomous safety required ___
Cost Sensitivity Bandwidth <$100/month $100-1,000/month >$1,000/month bandwidth ___
Cross-Device Correlation Independent devices Local correlation helpful Real-time multi-device fusion needed ___
Deployment Complexity Prefer simplicity Can manage fog nodes Already have local infrastructure ___

Scoring Instructions:

  1. For each row, mark which column describes your application
  2. Count your marks in each column:
    • Cloud Sufficient: 6-8 marks → Use cloud-only architecture
    • Fog Beneficial: 3-5 marks → Fog provides value but not essential - calculate ROI
    • Fog Mandatory: 2+ marks → Fog required - project cannot meet requirements without it

Example Application: Healthcare Patient Monitoring

Criterion Cloud Fog Mandatory Rationale
Latency ✓ Sepsis alerts must trigger within 30 seconds
Connectivity ✓ Must operate during network failures
Data Volume ✓ 100 patients × 5 vitals × 1 Hz = 500 readings/sec
Privacy ✓ HIPAA - PHI cannot leave hospital network
Safety-Critical ✓ Life-critical alerts cannot wait for cloud
Cost ✓ Bandwidth cost reasonable
Correlation ✓ Cross-patient outbreak detection
Complexity ✓ Hospital has IT staff

Result: 3 “Fog Mandatory” marks → Fog required - patient safety and HIPAA compliance make cloud-only architecture non-viable.

ROI Calculation Template:

If your scoring shows “Fog Beneficial” (borderline case), calculate financial justification:

Monthly Cloud Bandwidth Cost:
  Data rate (MB/sec) × 86,400 × 30 × $0.09/GB = $___/month

Monthly Fog Bandwidth Cost (assume 99% reduction):
  Above × 0.01 = $___/month

Monthly Savings:
  Cloud cost - Fog cost = $___/month

Fog Infrastructure Cost:
  N gateways × $800 = $___ one-time

Breakeven Time:
  Infrastructure cost ÷ Monthly savings = ___ months

Decision: If breakeven < 24 months, fog is financially justified

Decision Tree Summary:

  1. Any “Fog Mandatory” criteria met? → Use fog (no ROI calculation needed)
  2. All “Cloud Sufficient”? → Use cloud-only (simplest architecture)
  3. Mixed scoring? → Calculate ROI - fog justified if breakeven <24 months
Common Mistake: Fog-Washing - Running VMs On-Premises Without Fog Logic

The Trap: Teams deploy powerful servers on-premises, call them “fog nodes,” but run cloud-identical VMs that simply forward all data to the cloud. The result: fog’s cost and complexity without its benefits.

Real-World Example - Manufacturing Plant Deployment:

A food processing plant installed 10 Intel NUC servers (one per production line) and celebrated their “fog computing implementation.” Investigation revealed:

What they actually deployed:

  • Docker containers running Python scripts that subscribed to local MQTT broker
  • Scripts parsed JSON sensor messages, validated schema, then forwarded to AWS IoT Core via HTTPS
  • “Processing” consisted of: json.loads() → validate_schema() → requests.post(aws_url)
  • 100% of sensor data still reached the cloud (zero bandwidth savings)
  • Response time: 180ms (edge → NUC → AWS → NUC → edge)
  • Total cost: $8,000 hardware + $450/month cloud bandwidth

What fog computing should have done:

  • Threshold-based alerts: Generate alarm if temperature deviates >2°C from setpoint (no cloud needed)
  • Local aggregation: Send 1-minute averages instead of per-second readings (60× bandwidth reduction)
  • Anomaly detection: Flag outliers locally, only forward anomalies (95%+ reduction)
  • Offline operation: Make cooling/heating decisions locally during network outages

The actual savings they missed:

  • With proper fog filtering: 450 MB/day → 4.5 MB/day = 99% reduction = $4.50/month bandwidth
  • Monthly savings: $445.50
  • ROI: Already positive after 18 months

How to Avoid This:

Checklist - Your “Fog Node” is Real Fog If:

Warning Signs of Fog-Washing:

  • Architecture diagrams show a fog tier, but bandwidth bills haven’t decreased
  • “Fog node” codebase is just API forwarding logic with no domain-specific processing
  • System fails completely during network outages (no offline resilience)
  • Every sensor reading has a corresponding cloud message (no aggregation)

The Fix:

If your current deployment is fog-washed, implement these four critical fog functions:

  1. Threshold alerting: if temp > 75°C: send_alert(); else: discard_reading()
  2. Time-based aggregation: send_to_cloud(avg(last_60_readings)) every minute
  3. Offline decision buffer: if no_internet: run_local_pid_controller()
  4. Priority filtering: if is_anomaly(reading) or is_alarm(reading): forward_immediately()

These four patterns alone typically achieve 90-95% bandwidth reduction while enabling offline operation - the minimum bar for fog computing.

34.8 Summary

This overview chapter introduced the fog computing chapter series:

Key Takeaways

  1. Fog computing is an intermediate processing layer between edge devices and the cloud, optimized for low-latency decisions and bandwidth reduction

  2. Three-tier architecture:

    • Edge (sensors): Data collection, <1ms local response
    • Fog (gateways): Local processing, 5-50ms decisions, 90-99% bandwidth filtering
    • Cloud (data centers): Analytics, storage, 100-500ms latency

  3. Primary benefits of fog:

    • Latency reduction (200ms → 10ms for safety-critical decisions)
    • Bandwidth savings (99%+ reduction through local filtering)
    • Offline resilience (local operation when internet fails)
    • Privacy (sensitive data processed locally)

  4. Chapter roadmap:

    • Architecture → Applications → Cloudlets → Challenges
    • ~90 minutes total reading time
    • Progressive complexity from fundamentals to deployment pitfalls

Diagram showing the three-tier IoT architecture with Edge (sensors in orange) connecting to Fog (gateway in teal) connecting to Cloud (analytics in dark blue). A separate box shows the four key fog computing trade-offs: Low Latency (5-50ms), Bandwidth savings (90-99%), Resilience (offline capable), and Privacy (local processing). Uses IEEE colors throughout.

Cross-Hub Connections

Explore Related Learning Resources:

  • Simulations Hub: Try interactive fog computing simulators to visualize data flow across tiers
  • Videos Hub: Watch curated tutorials on fog architecture from Cisco and AWS
  • Quizzes Hub: Test your fog computing knowledge with comprehensive quiz banks
  • Knowledge Gaps Hub: Identify and address common misconceptions about edge vs fog vs cloud

34.10 Knowledge Check

34.11 What’s Next

Topic Chapter Description
Three-Tier Design Fog Architecture: Three-Tier Design and Hardware Design the three-tier hierarchy, select fog node hardware, and partition computation across layers
Real-World Deployments Fog Applications and Use Cases Case studies from Barcelona Smart City and BP Pipeline Monitoring with worked bandwidth calculations
Mobile Edge Computing Cloudlets: Datacenter in a Box VM synthesis techniques that create application environments 40-80x smaller than full VMs
Deployment Challenges Fog Challenges and Failure Scenarios Failure modes, sync storms, clock skew, and a production deployment checklist
Foundational Context Fog Fundamentals Core fog computing concepts if you have not already covered three-tier architecture basics