The Internet of Things describes physical devices with sensors, network connectivity and enough processing to report what they observe and act on instructions. The distinguishing feature is not that a device is online, but that it is deployed in large numbers, runs unattended for years, and is constrained in power, memory and compute.
01The layers of a deployment
Devices sit at the edge. Many run a microcontroller with kilobytes of memory rather than a general-purpose operating system, and may be battery powered with a target life measured in years. That constraint drives every other design decision, since a device that must sleep most of the time cannot hold an open connection or run heavy cryptography casually.
Connectivity is chosen against the same constraint. Short-range mesh and low-energy radio protocols suit dense indoor deployments; low-power wide-area networks suit sparse, distant sensors sending small payloads; cellular suits mobile assets; wired and powered connections suit anything that can have them. Range, data rate and battery life trade against one another, and there is no option that maximises all three.
Gateways aggregate devices that cannot reach the internet directly, translating a local protocol into a standard network one and often performing initial filtering.
Platform and applications handle device identity, message ingestion, storage, rules and dashboards. Lightweight publish-subscribe messaging is the common pattern here, because it suits many intermittent publishers and few subscribers better than request-response does.
02Edge and cloud
Processing can happen on the device, on a gateway, or centrally. Sending everything upstream is simplest but costs bandwidth, power and storage, and fails whenever connectivity does.
Processing at the edge reduces all of that and cuts response latency, which matters when a local decision must be made in real time. It also reduces privacy exposure, since data that is summarised locally never leaves the site. The usual pattern is a split: act locally on the immediate signal, send aggregates and exceptions upstream for analysis and long-term storage.
03The unglamorous parts that decide success
Provisioning. Every device needs a unique identity and credentials, installed in a way that scales to the deployment size and does not rely on a shared secret across the fleet.
Updates. Devices deployed for years will need firmware updates, and the update mechanism must be signed, verified, resumable and safe to interrupt — a failed update on an inaccessible device is an expensive site visit.
Security. Connected devices are attractive targets precisely because they are numerous, rarely monitored and often forgotten. The recurring failures are well known: default or shared credentials, no update path, unnecessary open services, and unencrypted transport. Placing devices on a network segment separate from trusted systems limits the damage when one is compromised.
Lifecycle. A device outlives the enthusiasm of whoever deployed it. Deciding in advance how long it will be supported, what happens when the backing service is retired, and how devices are decommissioned and their data disposed of is part of the design, not a later problem.