Networking
IoT Architecture
"IoT" isn't one protocol or one product — it's a handful of layers working together: a device, optionally a gateway, a cloud platform, and the applications built on top. Everything else in this notebook — sensors, protocols, security — is a piece that slots into one of these layers.
- What it is
- A layered system: device → (gateway) → cloud platform → application, with telemetry flowing up and commands flowing down.
- Mental model
- Not "a protocol" — a supply chain for data, where each layer's job is to move it one step closer to something a human or another system can act on.
- Key numbers
- 4 layers typically; two data directions (telemetry up, commands down) that need separate thinking.
- Reach for it when
- Designing anything beyond a single standalone device — the moment more than one device needs to be seen or managed centrally.
The layered architecture
The device layer is everything covered in Electronics, Sensors, and Embedded — this page picks up where those leave off, once the device is ready to talk to the outside world.
Device provisioning and identity
Before a device can participate in any of this, it needs a unique, cryptographically verifiable identity — otherwise the cloud platform has no way to know which physical device a given message came from.
- Factory provisioning
- A unique certificate/key is generated and installed during manufacturing — the most secure option, since the credential never travels over an untrusted channel after that point.
- Just-in-time provisioning
- A device authenticates with a shared "bootstrap" credential on first connect, and the platform issues it a unique certificate at that point — lower manufacturing complexity, but the bootstrap credential itself becomes something worth protecting.
OTA updates
Over-the-air firmware updates are usually the single most operationally important piece of a fleet's software lifecycle — see The Complete Boot Process for the bootloader-level mechanics (A/B partitions, bootargs pointing at whichever is current) and Snap types & Ubuntu Core for a full OS built around exactly this update model. At the fleet level, the concerns are different: staged rollouts (update 1% of devices before 100%), the ability to halt a bad rollout mid-flight, and bandwidth-conscious delta updates rather than shipping a full firmware image to every device on every change.
Telemetry vs. commands
It's worth treating these as genuinely separate design problems, not one "communication channel":
- Telemetry (device → cloud) — usually high volume, loss-tolerant, and time-series in nature (a sensor reading every few seconds). MQTT publish or periodic CoAP POSTs fit naturally.
- Commands (cloud → device) — usually low volume, and often needs delivery confirmation ("did the device actually receive and act on this?") that telemetry doesn't need at all — a different reliability requirement even over the same protocol.
Device shadows / digital twins
A device shadow (AWS IoT's term) or digital twin (the more general term) is a cloud-side cached copy of a device's last-known state and desired state. It matters because devices aren't always connected: an application can read or even set the "desired" state of an offline device against its shadow, and the device applies that desired state the next time it reconnects — without the application ever needing to know or care whether the device was online at the moment the request was made.
Choosing a protocol at each layer
| Protocol | Best fit here |
|---|---|
| CoAP | Individually constrained devices talking to a gateway, or directly to a CoAP-aware backend |
| MQTT | Device-to-cloud telemetry and command fan-out at fleet scale — the most common device-to-cloud choice |
| AMQP | Behind the cloud platform itself, routing ingested device data to the right internal services |
| HTTPS | Application-layer APIs, dashboards, and anything device-to-cloud that isn't latency- or power-sensitive |
Security, end to end
A real IoT deployment needs security at every layer, not just one: TLS/mTLS for the connection itself, unique per-device identity (above) so a compromised device can be individually revoked, and secure/verified boot so the device's own firmware can't be silently replaced by something malicious in the first place. Any one of these alone is a partial defense — a stolen shared credential defeats TLS just as completely as no TLS at all.
Real-world applications
- AWS IoT Core / Azure IoT Hub — managed cloud platforms providing device registry, MQTT ingestion, device shadows, and rules engines out of the box.
- ThingsBoard / Eclipse IoT — open-source alternatives for teams that want to self-host the platform layer rather than depend on a specific cloud vendor.
- balenaCloud — a fleet management platform built specifically around container-based OTA updates for Linux edge devices — the fleet-scale version of the A/B update concerns above.
- Home Assistant — a consumer-scale example of the same architecture in miniature — a local "gateway" aggregating many devices' MQTT traffic, with automations standing in for cloud-side rules.
- Industrial SCADA/telemetry systems — the same device/gateway/platform layering, often with CoAP or proprietary protocols at the device layer feeding into an industrial-grade broker.
For this same layering traced through one real device — two independent protocol adapters, a shared local bus, and a single cloud uplink — see Project-Based Example.
Gotchas
- Building full cloud infrastructure for a 3-device prototype is a common over-investment — the layered architecture is a target to grow into, not a checklist every project needs from day one.
- Device management (provisioning, OTA, fleet monitoring) is consistently underestimated until fleet size grows past what anyone can update by hand — planning for it early is much cheaper than retrofitting it onto thousands of already-deployed devices.
- Designing only for "always connected" devices is a design bug waiting to happen — real deployments lose connectivity constantly, and both telemetry buffering and command queuing need an explicit answer for "what happens while offline," not just "it'll reconnect eventually."
- Hardcoded, shared credentials baked into firmware are still extremely common in early prototypes and occasionally make it to production — per-device identity (above) isn't optional once a fleet exists, only easy to skip when there's just one device to test with.