openskills.info
Course Preview

Edge-to-Cloud IoT Architecture

Edge-to-cloud IoT architecture places sensing and immediate control near devices, then sends selected data to cloud services for fleet management, storage, and analysis. It helps you decide which work must stay local and which work benefits from central scale.

itComputer architecture and hardware

Don't Panic — Edge-to-Cloud IoT Architecture

Edge-to-cloud IoT architecture is the arrangement that lets physical equipment do the work that must happen nearby while a central service manages the wider collection. The equipment is in a factory, building, vehicle, or field site, which is inconveniently far from the tidy assumptions made by most diagrams.

The three places have different jobs. A device senses or acts on the physical world. The edge is nearby compute that translates local protocols, makes local decisions, and holds data when the connection goes away. The cloud keeps the fleet's shared record, deployment intent, long-term data, and cross-site analysis. This is not a contest between edge and cloud. It is a division of labor, like a very distributed office where the nearest person is also holding the valve.

Start with a physical outcome. Stopping a pump when its temperature becomes unsafe must have a local path. Comparing battery health across thousands of assets belongs in the cloud. That one distinction sorts much of the architecture: local latency, local protocols, and disconnected operation push work toward the device or edge; fleet-wide management and retention pull it toward the cloud.

Telemetry says what happened. A command asks for something to happen. An acknowledgment says whether the receiver accepted, applied, or rejected it. Keep those three separate, because a network connection is not proof that an action took place. Similarly, desired state is the configuration somebody requested; observed state is the evidence reported by the target after trying. Intent is useful. Evidence is better.

The awkward part is that the edge can store only a finite amount of unsent data. A store-and-forward queue holds messages until connectivity returns, but eventually the disk fills and the architecture must decide what to drop. That is not an edge case, despite the name's best efforts. It is one of the main cases.

Read the Intro for the full device-edge-cloud flow and the failure questions. Use Slides when the placement boundaries need a quick map. Keep the Cheatsheet nearby for contracts, command paths, and fleet signals. The Practice tab turns one representative site path into a reviewable design before a product choice makes the decision look permanent.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources