Welcome back!

In this lesson, I'll introduce to you to Azure IoT Hub, and we’ll cover some of its main features.

Let’s start by looking at what a generic IoT solution might look like at a high level.

You can see that that there are several components here. The backend here is where you can perform data processing and analytics. This can range from reasonably simple, to quite complex depending on what sort of processing you’re performing. And it’s often more than just a single application, though overall if you’re a developer this will be well within your wheelhouse.

Next, you have monitoring and control capabilities.
Next up there’s the presentation layer. This is broken out into two sub-components, which are a set of end-user user interfaces, and the business intelligence dashboards.

The end-user component may contain one or more user interfaces for interacting with the IoT solution.
And the BI layer will usually contain useful visuals of the data that support business decisions.

Last but not least, you have the devices.

When it comes to devices, depending on your skillset, this may be the difficult part of an IoT solution. If you’re a developer, especially a web or mobile developer, then you’re used to a certain set of rules. For example, you know where your code will be deployed and how users will interact with it.
When it comes to IoT devices, the rules may be different. The device may not even have the types of input/output that you’re used to. They might not have a keyboard, mouse or display. In addition to the I/O differences, the communication protocols may not be your standard, friendly HTTP. Sometimes low powered devices require different protocols in order to conserve energy.

The devices may also be deployed in places where internet connectivity is spotty, or practically non-existent.
So how do you develop for different devices, and how do you communicate with them?

The general way in an IoT solution is by introducing a tier between the devices and your backend solution that you can think of as the "device connectivity" tier.

Generally, the "device connectivity" tier consists of two components.

First, there is a "cloud gateway."
Then there is a "field gateway."

The cloud gateway is the cloud side of communications. It gives devices that are capable of communicating over internet protocol a highly available cloud endpoint to connect to in order to interact with the back-end solution. This could be the devices sending data to the backend, or the backend sending instructions back to the device.

A lot of devices will be able to communicate with a cloud gateway, however, sometimes you’ll have to work with legacy devices, or low powered devices that don’t communicate over IP.
This is where a field gateway helps out. This is some sort device that can be used to communicate with nearby devices, and then it will communicate with the cloud gateway. So the field gateway is kind of a middle man between the devices and cloud gateway.

So this is a high level generic look at how an IoT Solution might be structured. Now let’s see how IoT Hub fits into the same generic IoT solution.

Here’s the same generic solution, with an overlay showing IoT Hub’s role.
IoT Hub is the Cloud Gateway that you put between devices and your backend processes.
It gives you the functionality to communicate with, manage, and collect data from all of the devices.

IoT Hub has a lot of features for your solution.

Being a cloud native service means that it’s designed to scale, allowing you to support millions of devices.

It implements service assisted communication, since IoT Hub assumes that devices aren’t always available.

It is multi-platform by design.
In fact, there are SDKs for all the major IoT platforms.

It has multi-protocol support.
It supports the top three protocols for IoT, which are HTTP, AMQP and MQTT; but it’s also designed to support custom protocols, which means you can support legacy protocols. But it also helps to future proof your solutions.

It implements secure communication giving you per device authentication with individual identities and credentials.

IoT Hub implements cloud-scale bidirectional messaging which allows messages to be queued up until they can be processed. It also supports at-least-once messaging.
IoT Hub is all about messaging, it’s really a messaging gateway. All messages incoming or outgoing, go through an IoT Hub endpoint.
IoT Hub is an abstraction layer over a message queue layer. Actually IoT Hub endpoints are compatible with Event Hubs, allowing you to use the Event Hub SDKs.

IoT Hub is a messaging broker that supports devices, implementing resilience, availability, and scalability for them. This is what I referred to earlier as "service assisted communication."

IoT Hub can scale to million of devices, though when you scale, you don't think about resources, regions, CPU or memory.
Instead, you think about how many messages and devices you need to handle.

So when scaling with IoT Hub you scale based on units.

Units offer different capacity depending on the tier you select. Each tier supports a different number of messages that a unit can handle per day.

It’s worth mentioning, during the course, when I talk about messages, I’m referring to the message as a whole. Regardless of the size of the message.

When IoT Hub refers to a message it’s measuring it in 4 kilobyte chunks...at least for the billable tiers. So a 16 kilobyte message being sent from a device to IoT Hub, is actually billed as 4 messages.

So, when you start planning out your IoT solution and cost, you need consider the number of devices, messages and message size.

Okay, we’ve talked about it at a high level, however, let’s actually head into the portal and create a new IoT Hub app.

Here we are in the portal, so let’s click on New, and search for IoT Hub. Click on the IoT Hub option, and on this blade, click Create.

We need to give it a name…

And we also need to select a pricing and scale tier, and you see that you have a free tier and a standard S1, S2 and S3 tier.

It’s worth pointing out that you can only select a free tier once per subscription, and since I’ve already used it somewhere else in this subscription, I can’t use it again.

So, let’s use the S1 tier.

Then you can select how many units you want to use. Let’s leave this at 1, since we can increase the number of units anytime.

With the device to cloud partition you can use between 4 and 32 partitions. This can be used to improve the parallelism of reads. This parameter can’t change once the service is created. It doesn’t affect billing, but it does change the complexity of reading the messages.
If you don’t have any specific requirements, then leave this set to the default value.

Then you have to choose the subscription and the resource group,... and then you click Create.

So, here we have an IoT Hub instance that we’ll be using throughout the course.

Alight, this was a simple demo, however creating an IoT Hub app in the portal is pretty simple.
Okay, let’s summarize what we’ve covered in this lesson.

In this lesson, we looked at a generic IoT solution, and then saw where IoT Hub falls into it.
Then we covered the high level functionality of IoT Hub which has a lot of features to support device communication so that you can spend your time on device functionality and backend processing.

In the next lesson, we’ll talk about devices and developers.

See you in the next lesson!