In the previous post we covered what IoT is, why you’d use it, and which industries are putting it to work. Now it’s time to move from concept to platform.
Before we get to storage, analytics, or real-time alerting, there’s one service that every Azure IoT solution needs: Azure IoT Hub. It’s the entry point for all device data and the service that makes everything else possible.
In this post we’ll look at what IoT Hub is, what it actually does, and how it fits into the bigger picture of an IoT solution.
Where IoT Hub fits #
Picture an IoT system at a high level. You have devices out in the field generating data: temperature sensors, GPS trackers, industrial machines, whatever the use case. That data needs to get somewhere. There has to be a service in the cloud that receives it, something that acts as a gateway between the device world and the rest of your cloud infrastructure.
That gateway is IoT Hub.
The basic flow looks like this:
IoT Hub sits right in the middle between your devices and your cloud infrastructure. Everything coming from a device passes through it. Everything going back to a device passes through it too. If IoT Hub isn’t there, or isn’t configured correctly, your data goes nowhere.
What IoT Hub actually does #
IoT Hub is a fully managed PaaS service, which means Azure handles the underlying infrastructure. You don’t manage servers or message brokers. You just configure it and connect your devices to it.
Here’s what it gives you out of the box.
Secure, bi-directional communication #
IoT Hub supports communication in both directions: device-to-cloud (D2C) and cloud-to-device (C2D).
D2C is the most common direction: a device sends sensor readings or status updates up to the cloud. C2D goes the other way: you push a command or configuration change down to a specific device. Both directions are secured.
For protocols, IoT Hub supports MQTT, AMQP, and HTTPS. MQTT and AMQP are the preferred choices for IoT devices because they’re designed for unreliable networks and constrained hardware. HTTP works too, but it’s not a great fit for devices that send data continuously.
A device registry #
IoT Hub maintains a registry of every device allowed to connect. If a device isn’t registered, it can’t connect.
This might sound obvious, but it’s an important security boundary. In a real deployment you could have thousands of devices. The registry gives you a single place to manage which ones are authorized, and it stores identity information for each device.
Device management #
Beyond just registering devices, IoT Hub lets you configure and control them. You can update device settings, push firmware changes, and monitor device state. For large-scale deployments where physically reaching each device isn’t realistic, this is how you keep them up to date and behaving correctly.
Scale #
IoT Hub is built to handle serious scale. It can handle a million of connected devices and thousands of messages per second. Most IoT solutions will never come close to those numbers, but it’s good to know the ceiling is high. The service scales with your workload, so you’re not over-provisioning infrastructure for traffic you don’t have yet.
Temporary message storage #
When a device sends a message, IoT Hub holds onto it, but not forever. If nothing processes or routes that message within the retention window, it gets deleted.
This is an important constraint to understand. IoT Hub is not a data store. Getting data into IoT Hub is only half the job, you also need to route it somewhere useful before it disappears.
Message routing #
Message routing is how you tell IoT Hub what to do with incoming messages. You define one or more routes, each with a target service and a query condition. When a message matches the condition, it gets forwarded to that target.
This is how data ends up in long-term storage, how it gets streamed to an analytics service, and how it triggers real-time alerts. Routing is what connects IoT Hub to the rest of your architecture.
We’ll look at routing in detail in a later post. For now, the key point is that without routes, messages pile up in IoT Hub and then eventually vanish.
The three paths that follow #
Once a message arrives in IoT Hub, it needs to go somewhere. In a typical Azure IoT architecture, data splits into three processing paths depending on how urgently it needs to be acted on:
- Cold path - bulk storage for long-term archiving and historical analysis
- Warm path - near-real-time storage and monitoring dashboards
- Hot path - real-time alerting and immediate action
IoT Hub is the starting point for all three. The next post in this series covers this three-path architecture in detail, including which Azure services handle each path.
What comes next? #
In the next post we’ll look at the full Azure IoT architecture: the cold path, the warm path, and the hot path. Each one handles data differently depending on how quickly you need to act on it, and each maps to a specific set of Azure services.