Choosing the right Azure IoT Hub Edition

For our Band on the Run IoT project for the Microsoft Band, we use Azure IoT Hub as the ingestion point to push all the band telemetry up to Azure for processing.

If you have not come across it before, Azure IoT Hub is a fully managed service that enables reliable and secure bidirectional communications between millions of IoT devices and a solution back end. Azure IoT Hub:

• Provides reliable device-to-cloud and cloud-to-device messaging at scale.
• Enables secure communications using per-device security credentials and access control.
• Provides extensive monitoring for device connectivity and device identity management events.
• Includes device libraries for the most popular languages and platforms.

Whilst Azure IoT hub supports bidirectional communication, we only use the device-to-cloud (aka “d2c”) capabilities.

 

 

Azure IoT Hub is offered in three editions:

(pricing correct as of April 2016 – please check the latest pricing information)

Free: The Free edition is designed to transmit up to a total of 8,000 messages a day, and is suitable for gaining familiarity and testing out the capabilities of the IoT Hub service. Note: IoT Hub only allows one free hub per subscription.

S1: IoT Hub S1 edition is designed for IoT solutions that generate relatively small amounts of data. Each unit of the S1 edition allows up to 400,000 messages per day across all connected devices.

S2: IoT Hub S2 edition is designed for IoT solutions that generate large amounts of data. Each unit of the S2 edition will allow up to 6 million messages per day across all connected devices.

When we first started development we used the free edition, as it was a really great way to get up and going. However, as we started to expand the architecture, add more capability, and have other colleagues at Microsoft want to demonstrate the solution, so we had to move to S1. The main reasons to move was message throughput.  That limit of 8,000 messages a day sounds quite high, but our UWP app was pushing out one message per second, a frequency that was based on the rate at which the Microsoft Band transmits heart rate data through the Microsoft Band SDK. That’s just over two hours of constant use, so we very quickly reached the daily limit. Obviously we could easily reduce the frequency of transmission with negligible impact, and we could buffer up the telemetry into a single call,as our payload is very small. Bit, as we support multiple bands, once again, when a lot of people start using it, it would take us over the limit very quickly. So we moved over to an S1 edition,

Once you start getting into scale, these sorts of calculations and architectural design decisions get increasingly important. One thing that may not be obvious from the way the pricing is laid out, is that this pricing is per unit, and you can have up to 200 units in a subscription (that limit is a soft limit I understand, and can be raised upon request).

You can read more about provisioning an Azure IoT Hub unit.

There are some other aspects of scale you need to be aware of when designing these types of solutions. The best way to size an IoT Hub solution is to evaluate the traffic on a per-unit basis. Device-to-cloud messages follow these sustained throughput guidelines:

So think about the payload sizes and think through any peak scenarios.

You also need to be aware of the IoT Hub quotas and throttles and design accordingly.