55 Edge Architecture Review
55.1 Learning Objectives
Key Concepts
- Three-tier IoT architecture: The canonical edge/fog/cloud layering where device-level microcontrollers, gateway-level fog nodes, and cloud servers each handle processing tasks matched to their resource capabilities and latency requirements.
- Partition decision: The choice of which pipeline stage marks the boundary between local (edge/fog) and remote (cloud) processing, optimised to meet latency, bandwidth, and accuracy requirements simultaneously.
- Protocol bridging: The translation of device-side protocols (Modbus, BLE, Zigbee) to cloud-side protocols (MQTT, HTTPS) at the gateway tier, enabling heterogeneous devices to connect to standard cloud platforms.
- Edge node taxonomy: Classification of edge processing hardware by resource tier: Class 1 (microcontroller, 32 KB–4 MB, <100 MHz), Class 2 (SBC/SoC, 64 MB–4 GB, 1–2 GHz), Class 3 (x86 gateway, 4–64 GB, 2–4 GHz).
- Southbound/northbound interfaces: Southbound interfaces connect the gateway to field devices (sensors, actuators); northbound interfaces connect the gateway to cloud or enterprise systems; both must be explicitly designed and secured.
By the end of this chapter, you will be able to:
- Identify Architecture Patterns: Distinguish between edge, fog, and cloud computing tiers and their roles
- Apply Decision Frameworks: Use structured decision trees to select optimal processing locations
- Evaluate Trade-offs: Assess latency, bandwidth, privacy, and cost trade-offs for different architectures
- Match Use Cases: Map IoT application requirements to appropriate architectural patterns
- Compare Massive vs Critical IoT: Distinguish the distinct requirements of high-volume delay-tolerant versus low-latency mission-critical deployments
55.2 Prerequisites
Required Reading:
- Edge Compute Patterns - Edge computing basics
- Edge Comprehensive Review - Full review
Related Chapters:
- Edge Review: Calculations - Formulas and practice problems
- Edge Review: Deployments - Real-world patterns
For Beginners: Why Architecture Matters
Think of IoT architecture like choosing where to cook a meal:
- Edge (your kitchen): Fast, private, but limited equipment
- Fog (neighborhood restaurant): More equipment, serves multiple homes
- Cloud (factory kitchen): Massive scale, can serve thousands, but delivery takes time
The right choice depends on what you are cooking (your data), how quickly you need it (latency), and how many people you are serving (scale). This chapter helps you make that choice systematically.
55.3 Core Concepts Summary
55.3.1 Edge Computing Terminology
| Concept | Definition | Key Characteristics |
|---|---|---|
| Edge Computing | Processing data near its source (IoT devices) | Low latency (<10ms), reduced bandwidth, local autonomy |
| Fog Computing | Intermediate layer between edge and cloud | Aggregation, preprocessing, hierarchical architecture |
| Cloudlet | Small-scale data center at network edge | VM-based edge services, mobile edge computing |
| MEC (Multi-access Edge Computing) | Telco edge infrastructure at cell towers | 5G integration, ultra-low latency, operator-managed |
| Edge Gateway | IoT Reference Model Level 3 | Evaluate, format, reduce data before cloud |
| Data in Motion | Streaming data from devices (Levels 1-3) | Event-driven, real-time processing |
| Data at Rest | Stored data in databases (Level 4+) | Batch processing, historical analysis |
55.3.2 IoT Reference Model: Edge-Relevant Levels (1-4)
The Cisco IoT Reference Model defines seven levels from physical devices (Level 1) through collaboration and processes (Level 7). For edge architecture decisions, the first four levels are most relevant because they determine where data is processed before reaching the application layers. See IoT Reference Models for the complete seven-level model.
| Level | Name | Function | Processing Type |
|---|---|---|---|
| Level 1 | Physical Devices & Controllers | Sensors, actuators, embedded systems | Local sensing, basic control |
| Level 2 | Connectivity | Communication protocols, gateways | Reliable data transport |
| Level 3 | Edge Computing | Data reduction, filtering, formatting | Real-time preprocessing |
| Level 4 | Data Accumulation | Storage systems, databases | Long-term storage, batch analytics |
55.3.3 Edge Gateway Three Functions (EFR Model)
| Function | Purpose | Examples |
|---|---|---|
| Evaluate | Filter low-quality or invalid data | Discard out-of-range values, check sensor health |
| Format | Standardize data for cloud ingestion | Convert units, normalize timestamps, add metadata |
| Reduce (Distill) | Minimize data volume before transmission | Downsample, aggregate, compute statistics |
55.4 Edge vs Cloud Trade-off Matrix
55.4.1 Architectural Trade-offs
| Factor | Edge | Cloud | Hybrid |
|---|---|---|---|
| Latency | <10ms (local) | 50-200ms (network delay) | Variable (critical=edge, batch=cloud) |
| Bandwidth Cost | Low (minimal WAN traffic) | High (continuous uploads) | Medium (selective sync) |
| Processing Power | Limited (constrained devices) | Unlimited (elastic scaling) | Flexible (offload when needed) |
| Data Privacy | Local (stays on-premise) | Concerns (third-party servers) | Selective (sensitive=edge) |
| Maintenance | Distributed (physical access) | Centralized (remote updates) | Complex (dual management) |
| Storage Capacity | Limited (local disks) | Petabyte-scale | Tiered (hot=edge, cold=cloud) |
| Reliability | Single point of failure | Redundant infrastructure | Failover capability |
| Cost Model | CapEx (upfront hardware) | OpEx (pay-as-you-go) | Mixed |
55.4.2 Use Case Suitability
| Application | Best Architecture | Justification |
|---|---|---|
| Autonomous Vehicles | Edge-heavy | <10ms latency required for safety, no cloud dependency |
| Predictive Maintenance | Hybrid | Edge for anomaly detection, cloud for fleet-wide trends |
| Smart Home | Edge-heavy | Privacy, works during internet outages |
| Video Surveillance | Hybrid | Edge for motion detection, cloud for long-term storage |
| Agricultural Monitoring | Hybrid | Edge for irrigation control, cloud for historical analysis |
| Industrial Safety | Edge-heavy | Real-time shutdowns, no network dependency |
| Customer Analytics | Cloud-heavy | Aggregate across locations, complex ML models |
| Energy Optimization | Hybrid | Edge for load balancing, cloud for demand forecasting |
55.5 Architecture Patterns
55.5.1 Hierarchical Edge-Fog-Cloud Architecture
55.5.2 Processing Location Decision Tree
55.5.3 Data Reduction Pipeline
55.6 Massive IoT vs Critical IoT
The 3GPP standards body formally distinguishes two IoT traffic profiles that demand fundamentally different edge architectures. Getting this distinction wrong leads to either over-engineering (spending $50 per node on hardware that only needs $2 worth) or under-engineering (deploying delay-tolerant infrastructure for life-safety applications).
| Characteristic | Massive IoT | Critical IoT |
|---|---|---|
| Scale | 100,000+ devices per km2 | 10-1,000 devices per site |
| Latency tolerance | Seconds to minutes | Sub-10ms mandatory |
| Reliability | Best-effort (99%) | Ultra-reliable (99.999%) |
| Data rate per device | <100 kbps | 1-100 Mbps |
| Power | Battery (5-10 year life) | Mains-powered acceptable |
| Cost per node | <$5 target | $50-$500 acceptable |
| Example protocols | NB-IoT, LoRaWAN, Sigfox | 5G URLLC, TSN, PROFINET |
| Example applications | Smart metering, agriculture, asset tracking | Autonomous vehicles, surgical robots, industrial safety |
Why this matters for architecture: A smart agriculture deployment with 50,000 soil sensors reporting hourly moisture readings (Massive IoT) can tolerate cloud-only processing because a 500ms delay is irrelevant when readings arrive every 3,600 seconds. In contrast, a robotic welding cell where a collision must trigger emergency stop within 1ms (Critical IoT) cannot involve any network hop beyond the local edge controller.
Real-world hybrid example: A smart factory floor typically runs both profiles simultaneously. Thousands of environmental sensors (temperature, humidity, vibration) operate as Massive IoT through LoRaWAN gateways with cloud analytics. Meanwhile, 20-30 robot safety interlocks operate as Critical IoT through local PLCs with sub-millisecond response. The two profiles share the same physical space but use completely different communication stacks, processing tiers, and reliability budgets.
Putting Numbers to It
Massive IoT vs Critical IoT: Quantifying the Architectural Differences
Consider a smart factory with both traffic types. The math shows why they need separate infrastructure:
Massive IoT Network (10,000 environmental sensors): \[ \text{Data Rate per Device} = \frac{100 \text{ bytes}}{3600 \text{ seconds}} = 0.028 \text{ bytes/sec} \] \[ \text{Total Aggregate Rate} = 10{,}000 \times 0.028 = 280 \text{ bytes/sec} = 24 \text{ MB/day} \] \[ \text{Latency Budget} = 60 \text{ seconds (acceptable delay)} \] \[ \text{Reliability Target} = 99\% \text{ (packet loss tolerable)} \]
Critical IoT Network (30 safety interlocks): \[ \text{Data Rate per Device} = \frac{50 \text{ bytes}}{0.001 \text{ seconds}} = 50{,}000 \text{ bytes/sec} \] \[ \text{Total Aggregate Rate} = 30 \times 50{,}000 = 1.5 \text{ MB/sec} = 130 \text{ GB/day} \] \[ \text{Latency Budget} = 1 \text{ ms (hard real-time)} \] \[ \text{Reliability Target} = 99.999\% \text{ (< 1 failure per 100,000)} \]
Cost per Device: \[ \text{Massive IoT} = \$5 \text{ hardware} + \$1/\text{year connectivity} = \$6 \text{ (amortized)} \] \[ \text{Critical IoT} = \$300 \text{ hardware} + \$0 \text{ connectivity (wired)} = \$300 \]
Network Capacity Requirements: \[ \text{Massive IoT LoRaWAN} = \frac{10{,}000 \text{ devices}}{1{,}000/\text{gateway}} = 10 \text{ gateways at } \$500 = \$5{,}000 \] \[ \text{Critical IoT TSN/PROFINET} = \frac{30 \text{ devices}}{30/\text{PLC}} = 1 \text{ PLC at } \$15{,}000 = \$15{,}000 \]
The 50x cost difference per device and 3x gateway cost difference justify separate architectures – mixing them would either over-provision Massive IoT ($50 to $300/node) or under-provision Critical IoT (cannot meet 1ms latency).
55.6.1 IoT Profile Cost Explorer
Use this calculator to compare infrastructure costs for Massive IoT versus Critical IoT deployments at different scales.
55.7 Workload Placement Decision Framework
55.7.1 Comprehensive Decision Tree
55.7.2 Workload Placement Guidelines
| Workload Type | Best Location | Justification |
|---|---|---|
| Safety-critical control | Edge | Cannot depend on network |
| Immediate alerting | Edge | <10ms response needed |
| Data filtering/validation | Edge | Reduce bandwidth 10-100x |
| Local dashboards | Edge | Works during outage |
| Sensor fusion | Edge/Fog | Combine multiple inputs locally |
| Anomaly detection (rules) | Edge | Simple thresholds |
| Anomaly detection (ML) | Fog | GPU for inference |
| Historical analysis | Cloud | Access to all locations |
| Model training | Cloud | Massive datasets, compute |
| Regulatory reporting | Cloud | Centralized compliance |
| Cross-site optimization | Cloud | Global view needed |
55.8 Case Study: Walmart’s Edge-Fog-Cloud Architecture for Refrigeration Monitoring
Walmart operates over 4,700 US stores, each containing 50-100 refrigeration units that must maintain temperatures between -18C (frozen) and 4C (fresh). A single refrigeration failure can destroy $10,000-$35,000 in perishable inventory within hours. Before 2019, temperature monitoring relied on manual walk-through checks twice daily – a 12-hour gap where failures went undetected.
Architecture deployed (2019-2021):
| Tier | Components | Processing | Latency |
|---|---|---|---|
| Edge (per unit) | Wireless temp sensor + BLE gateway | Threshold alerting: triggers local alarm if temp exceeds limits for >5 minutes | <500ms |
| Fog (per store) | In-store edge server (Dell Edge Gateway 5100) | Aggregates 50-100 sensors, runs compressor anomaly detection model (gradient boosted tree, 12 MB), correlates door-open events with temp spikes | 2-5 seconds |
| Cloud (centralized) | Azure IoT Hub + Databricks | Fleet-wide pattern analysis across 4,700 stores, seasonal demand forecasting, predictive maintenance scheduling | 30-60 seconds |
Why not cloud-only? Walmart calculated that sending raw temperature readings (every 30 seconds from 350,000+ units) to the cloud would cost approximately $2.1 million per year in cellular data alone. The fog tier reduces data volume by 97% – only anomalies, hourly summaries, and compressor health scores are transmitted to the cloud.
Why not edge-only? The compressor anomaly detection model requires correlating temperature trends with door-open frequency, defrost cycles, and ambient store temperature – data from multiple sensors that only the fog tier can aggregate. The edge sensor has 64 KB RAM and cannot run the model.
Results after 18 months:
- $86 million saved in prevented inventory loss (vs. manual-check baseline)
- Compressor failures predicted 3-7 days early in 73% of cases (fog-tier model)
- Store energy costs reduced 8% through cloud-tier optimization of defrost scheduling across climate zones
- Mean time to detect refrigeration failure: reduced from 6 hours to 47 seconds
Architecture lesson: The three-tier split was driven by three distinct latency requirements – immediate local alerting (edge), real-time anomaly detection (fog), and fleet optimization (cloud). Each tier earned its place by solving a problem the other tiers could not.
Decision framework applied to this case:
| Question | Answer | Architecture Implication |
|---|---|---|
| Is sub-second response required? | Yes (compressor failure alert) | Edge tier mandatory |
| Does processing need multi-sensor correlation? | Yes (temp + door + defrost + ambient) | Fog tier mandatory |
| Is fleet-wide optimization valuable? | Yes (defrost scheduling across climate zones) | Cloud tier mandatory |
| Can you tolerate internet outage? | No (food safety regulations require continuous monitoring) | Edge must operate independently |
| What is the data reduction ratio? | 97% (only anomalies and summaries to cloud) | Fog tier pays for itself in bandwidth savings |
Common Pitfalls
1. Designing the edge architecture without profiling resource usage
Specifying an edge processing pipeline without measuring its memory footprint, CPU utilisation, and power draw on the actual target hardware will lead to components that fail to fit or drain the battery faster than expected.
2. Building a monolithic edge application
A single binary handling sensor acquisition, protocol conversion, analytics, and cloud communication fails catastrophically when any one function encounters a bug or resource exhaustion. Structure edge software as independent, supervised processes.
3. Neglecting northbound security in gateway architecture
Much attention goes to securing the southbound device connection, but northbound cloud credentials stored in plaintext on a gateway are an equally serious vulnerability. Use secure key storage for all northbound cloud authentication credentials.
4. Not defining failure modes and recovery procedures
Every edge architecture review must specify what happens when the network is unavailable, the cloud is unreachable, a sensor fails, or the gateway reboots mid-transmission. Without defined failure modes, production incidents become unrecoverable.
55.9 Summary and Key Takeaways
55.9.1 Core Architecture Principles
- Process data as close to the source as possible to minimize latency and bandwidth
- Edge gateways perform Evaluate-Format-Reduce (EFR) functions before cloud upload
- The Cisco IoT Reference Model has 7 levels (devices through collaboration); edge architecture decisions focus on Levels 1-4
- Massive IoT (high volume, delay tolerant) vs Critical IoT (low latency, high reliability) require different architectures
- Hybrid architectures combine edge real-time processing with cloud analytics
55.9.2 Architecture Selection Summary
| Aspect | Edge Advantage | Cloud Advantage |
|---|---|---|
| When to use | Real-time, safety-critical, privacy-sensitive | Historical analysis, complex ML, cross-site aggregation |
| Data strategy | Filter and reduce locally | Store everything for long-term insights |
| Processing | Simple rules, lightweight ML | Deep learning, big data analytics |
| Failure mode | Local autonomy during outage | Redundant, always-available infrastructure |
Key Takeaway
Edge computing architecture follows five core principles: process data close to the source, use Evaluate-Format-Reduce (EFR) at gateways, understand the 7-level Cisco IoT Reference Model (with Levels 1-4 driving edge decisions), distinguish Massive IoT from Critical IoT requirements, and default to hybrid architectures that combine edge real-time processing with cloud analytics. The right architecture depends on latency needs, bandwidth constraints, privacy requirements, and whether your deployment prioritizes scale or safety.
For Kids: Meet the Sensor Squad!
“Choosing the Right Kitchen!”
The Sensor Squad was planning a big meal for the entire Smart City, and they needed to figure out where to cook.
“I will cook everything in my tiny kitchen!” said Max the Microcontroller (the edge). “I am super fast – I can make a sandwich in 10 milliseconds!”
“But your kitchen is small,” said Sammy the Sensor. “You can only make simple meals. What about the fancy AI-powered recipes?”
“That is where I come in!” announced the Cloud, a massive factory kitchen in the sky. “I can cook for thousands of people and use the fanciest recipe books. But delivering food takes 200 milliseconds because I am far away.”
“And I am the neighborhood restaurant!” said the Fog Node. “I am bigger than Max’s kitchen but closer than the Cloud. I can handle medium-sized jobs.”
Lila the LED drew a diagram on the board: “So here is how we decide:”
- “Need food in 10 milliseconds? (Emergency!) Cook at Max’s kitchen (EDGE)”
- “Need to analyze recipes from 100 restaurants? Use the Cloud!”
- “Need something in between? The Fog restaurant helps!”
Bella the Battery added the clincher: “And for safety – like detecting a gas leak – ALWAYS cook at the edge. You cannot wait for a delivery from the Cloud when there is an emergency!”
“That is called a HYBRID approach,” Max explained. “I handle the fast, important stuff. The Cloud handles the big, brainy stuff. Together we are unstoppable!”
What did the Squad learn? IoT architecture is like choosing where to cook: edge for speed and safety, cloud for scale and smarts, and hybrid for the best of both worlds!
55.10 Knowledge Check
Worked Example: Architecting Edge Processing for Smart Retail Chain
A retail chain with 500 stores deploys 20 cameras per store (10,000 cameras total) for customer analytics. Each camera generates 1080p video at 30 FPS. Design a three-tier edge-fog-cloud architecture showing data flow and reduction at each tier.
Raw data generation (per camera):
- 1080p @ 30 FPS: ~3 Mbps bitrate (H.264 compression)
- Per store (20 cameras): 20 x 3 Mbps = 60 Mbps = 7.5 MB/second
- Per store per day: 7.5 MB/s x 86,400 seconds = 648 GB/day
- Total 500 stores: 648 GB x 500 = 324 TB/day raw video
Tier 1 - Edge (in-store processing on NVIDIA Jetson Nano):
- Run person detection CNN (YOLOv5) at 30 FPS per camera
- Extract metadata: person count, dwell time, heatmap coordinates (not full video frames)
- Per camera: 30 FPS x 50 bytes metadata = 1,500 bytes/second
- Per store: 20 cameras x 1,500 = 30,000 bytes/s = 30 KB/s
- Reduction: 7.5 MB/s to 30 KB/s = 250x reduction at edge
Tier 2 - Fog (regional server covering 50 stores):
- Aggregate foot traffic patterns across 50 stores in region
- Compute hourly store visit statistics: peak hours, avg dwell time, section popularity
- Per region uplink: 50 stores x 30 KB/s = 1.5 MB/s raw metadata
- After fog aggregation: hourly summaries (1 update per hour per store) = 50 x 200 bytes/hour / 3600 = 2.8 bytes/second
- Reduction: 1.5 MB/s to 2.8 bytes/s = 535,714x reduction at fog
Tier 3 - Cloud (central analytics):
- 10 regional fog nodes x 2.8 bytes/s = 28 bytes/second
- Daily data: 28 x 86,400 = 2.4 MB/day total for 500-store chain
- Original raw: 324 TB/day
- Overall reduction: 324 TB to 2.4 MB = 135 million x reduction
Cost comparison:
- Cloud video storage: 324 TB/day x 30 days = 9,720 TB/month = 9,720,000 GB x $0.02/GB = $194,400/month
- Metadata-only storage: 2.4 MB/day x 30 days = 72 MB/month = negligible cost
- Edge inference hardware: 500 stores x $199 (Jetson Nano) = $99,500 one-time
- ROI: Hardware pays for itself in 0.5 months (vs cloud video transmission/storage)
This example demonstrates that edge AI inference (person detection) combined with fog-tier aggregation makes large-scale video analytics economically viable – streaming 324 TB/day of raw video to the cloud would be cost-prohibitive.
55.10.1 Edge Data Reduction Calculator
Explore how different deployment scales affect data reduction ratios and cost savings across the three-tier architecture.
Decision Framework: Edge vs Fog vs Cloud by Latency and Scale
| Requirement | Edge (Device) | Fog (Local Aggregation) | Cloud (Centralized) |
|---|---|---|---|
| Latency needed | <10ms | 10-100ms | >100ms acceptable |
| Scale (devices) | 1-100 | 100-10,000 | 10,000+ (unlimited) |
| Compute complexity | Simple rules, lightweight ML | Multi-sensor fusion, regional analytics | Deep learning training, cross-site correlation |
| Network dependency | Must work offline | Tolerates brief outages | Requires connectivity |
| Data privacy | Data stays on-premise | Regional boundaries respected | Data leaves site (compliance concerns) |
| Cost model | CapEx (upfront hardware) | Hybrid (gateway + connectivity) | OpEx (pay-per-use) |
| Example platforms | ESP32, Arduino, STM32 | Raspberry Pi 4, NVIDIA Jetson | AWS IoT Analytics, Azure IoT Hub |
| Best use case | Airbag deployment, collision avoidance | Factory floor dashboards, store analytics | Predictive maintenance across global fleet |
Selection heuristic:
- Start at the cloud, move left only if necessary: Begin with cloud analytics (easiest to develop/deploy). Move to fog if latency or bandwidth costs become prohibitive. Move to edge only when real-time control (<10ms) is safety-critical.
- Latency dictates tier: <10ms = edge, <100ms = fog, >100ms = cloud
- Scale determines hierarchy: <100 devices = cloud-only, 100-10K = fog+cloud, >10K = edge+fog+cloud
- Regulatory compliance: GDPR/HIPAA may mandate edge/fog for sensitive data (PII, health records)
Common Mistake: Deploying Edge AI Without Considering Model Staleness
Teams deploy ML models to edge devices (e.g., person detection on cameras, anomaly detection on sensors) but forget that models degrade over time as real-world conditions change. A person detection model trained on summer clothing fails in winter when everyone wears bulky coats.
What goes wrong: A smart factory deploys vibration-based anomaly detection on 100 machines, with models trained on 3 months of historical data. The models run locally on edge gateways for real-time alerting. Over 12 months, the factory gradually shifts production from aluminum parts (low vibration) to steel parts (higher baseline vibration). The anomaly detection model, still calibrated for aluminum, generates 50+ false alarms per day because normal steel vibration exceeds the aluminum-trained threshold.
Why it fails: Edge-deployed models are “frozen” – they do not adapt to changing conditions unless explicitly updated. Meanwhile, cloud models can retrain nightly on fresh data. The longer an edge model runs without updates, the more it drifts from reality.
The correct approach:
Implement model versioning and over-the-air updates:
import time # Edge device checks for model updates daily if time.time() - last_model_check > 86400: # 24 hours new_model = check_server_for_update() if new_model.version > current_model.version: download_and_replace_model(new_model)Monitor model performance metrics at the edge:
- Track prediction confidence scores over time
- Alert if average confidence drops below threshold (indicates model drift)
- Example: if person detection confidence was 95% in month 1 but 75% in month 6, model needs retraining
Use hybrid edge-cloud approach for model training:
- Edge: run inference with current model (low latency)
- Cloud: collect edge inference logs + ground truth labels, retrain model weekly
- Edge: receive updated model via OTA push
Real consequence: A facial recognition system for office access control deployed edge models on cameras at building entrances. Models were trained in 2023 and never updated. By 2025, employees wearing face masks (post-pandemic) had 40% false rejection rate because the model was not trained on masked faces. Security reverted to manual badge-only access, defeating the entire purpose of the biometric system. The fix: implement monthly model retraining using recent camera footage, with automated OTA deployment to all edge cameras. Model accuracy recovered to 98% within 2 months. The lesson: edge AI systems MUST include a model lifecycle management process – training, versioning, deployment, monitoring, and retraining – or models will degrade and fail over time.
55.11 See Also
Related Resources
Architecture Foundations:
- IoT Reference Models - Full seven-level Cisco model
- Edge, Fog, and Cloud - Three-tier deep dive
Within This Module:
- Edge Compute Patterns - Foundation concepts
- Edge Processing Patterns - Four edge patterns
- Edge Patterns Practical - Interactive latency calculator
- Edge Topic Review - Complete review index
55.12 What’s Next
| Current | Next |
|---|---|
| Edge Architecture Review | Edge Review: Calculations |
Related topics:
| Chapter | Focus |
|---|---|
| Edge Review: Deployments | Real-world deployment patterns and technology stack |
| Edge Topic Review | Main review index |