The course is part of these learning paths
Azure Artificial Intelligence Services
Design for IoT
Design Messaging Solution Architectures
Design Media Service Solutions
The Microsoft Azure 70-535 exam has a large section focused on creating practical solutions using Azure technologies. About 10-15% of the exam will cover Azure products focused on AI, Messaging, Internet of Things, and Video Media. This will require familiarity with dozens of Azure solutions.
This course will take you through all of the relevant technologies and ensure you know which ones to pick to solve specific problems. After taking this course you should be well-prepared for the 70-535 exam. However this is not only a test prep course. This course is also for developers, engineering managers, and cloud architects looking to get a better understanding of Azure services.
Whether your app deals with artificial intelligence, managing IoT devices, video media, or push notifications for smart phones - Azure has an answer for every use case. This course will help you get the most out of your Azure account by preparing you to make use of many different solutions.
Design solutions using Azure AI technologies
Design solutions for IoT applications using Azure technologies
Create a scalable messaging infrastructure using Azure messaging technologies
- Design media solutions using Azure media technologies and file encoding
People who want to become Azure cloud architects
People preparing for Microsoft’s 70-535 exam
General knowledge of IT architecture
Internet of Things software infrastructure is all about messaging and events. In the next major section we will do a deep dive on messaging infrastructure in Azure. For this section all you need to understand is that messages between IoT devices and the cloud backend are used to transmit events. These events could be temperature measurements from an IoT thermostat, humidity readings from an IoT greenhouse monitor, a configuration change for an IoT home light switch, or any other sort of data transmission.
So how do we handle these events efficiently? Well, you could build our own event handling system using something like Apache Kafka. If you have the expertise in-house, this could work well, but it will take time and effort.
Here is where Azure comes in. Azure has a number of different solutions for managing IoT events. We’re going to talk about event handling in two parts. First we’ll talk about initial event ingestion and processing. That will entail an explanation of three core Azure technologies - Azure Event Hubs, IoT Hub, and Azure Service Bus. Next, we’ll talk about actually using the ingested event data both by end users and our backend services. Relevant technologies here are Azure Notification Hub, Azure Stream Analytics, and Azure Event Grid.
So let’s start with event ingestion. Azure Service Bus, Event Grid, and IoT Hub are all capable of ingesting events - they just go about it in different ways. Service Bus is the more generalized solution. It is not strictly speaking an event ingestion system. Rather it is a managed message broker. Like Kafka or RabbitMQ, Service Bus is designed to decouple applications and services from each other with a reliable system for asynchronous state transfer.
Not all messages are events but all events are messages. Again, we’ll dig into the concept of messages in section three. Service Bus can do much of what IoT Hub and Event Hub can do, only it is not specialized around events or IoT. It doesn’t integrate with all of the same Azure services as well. As you can see from the documentation link, whatever your needs, Service Bus can likely accommodate you. The enterprise level support and security make it great for sensitive data like financial transactions. What’s more it has strong library support for .NET as well as Java and JMS.
Service Bus really shines when you need to support a variety of state transfer paradigms. Perhaps you need transactions that let you group operations together. Perhaps you need batching, or scheduled delivery of messages.
However this whole section is on IoT, and as we discussed IoT is focused on events. While Service Bus can serve as our main event ingestion system, it would require more development knowledge to get it to do everything we want. To make it easier for us to focus on events and in particular IoT, Azure offers IoT Hub and Event Hubs.
You can think of IoT Hub as a specialized version of Event Hub. Event Hubs act as the “front door” for your data. As you can see from the diagram, event data can come from a range of sources. End user devices, laptops, phones, tablets, software applications, devices, clients - all kinds of things can transmit event data. They need a place to send that data to - an endpoint essentially that speaks their language and understands the event data it is receiving.
So as an event ingestor Event Hub will have a few responsibilities. It has to validate that event data is properly formatted. It will use SAS tokens to identify and authenticate the event publisher. It will capture data and store it in an Azure storage service if needed. Even nicer: Event Hub can scale with your app. You control traffic using throughput units that can handle a certain number of MB per second. You can manually scale through the portal or enable auto-inflate to let Azure scale for you.
So what about IoT Hub? Why pick it over Event Hub? To add to your initial skepticism, know that IoT Hub is more expensive than Event Hub. So why go to the trouble and cost of using it instead of Event Hub or Service Bus? Simple: It provides functionality for IoT workloads that you won’t find anywhere else.
With IoT Hub you get the ability to not only ingest data from clients but also to easily push data back to those same endpoints. This can be hugely valuable for managing IoT devices. You get access to the Azure IoT Edge system that enable on-device data processing for analytics, app changes, configuration, and security. IoT Edge in particular is very powerful from some use-cases as we’ll see in a bit. Key takeaway is that IoT Hub is like Event Hub on steroids...Magic steroids that grant powers for IoT...Anyway, see the chart for a proper feature comparison.
(link comparing IoT Hub and event Hubs: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-compare-event-hubs)
So now that the event data has been ingested either using Service Bus, Event Hubs, or IoT Hubs, we want to do stuff with those events. Most likely we want to do one of two things. We either want to pass those events on to some other service to power our application or business logic, or, we want to immediately start analyzing that data directly and start deriving insights.
So let’s start with the former case. How can we easy mobilize all of this ingested data? Azure Event Grid is the answer. Event Grid is basically a managed intelligent routing service that consumes events in a publish-subscribe model. So take a look at the diagram here. As you can see Event Grid is basically a middle layer between your event ingestion systems and your downstream services.
You can see it supports Service Bus, Event hubs, and IoT Hubs as topics for ingestion. However it can also take in data from other Azure components such as Media Services and Blob Storage. The services that will then subscribe to your Event Grid will depend on your infrastructure. So for example you may have an Azure Function or an Azure Logic App that is powered by event data pulled from an Event Grid subscription. Your app then takes that event data, which may have originated from some user activity, and then return some output or value to the end user.
Event Grid is easy to set up using the Azure portal. All you need to do is define a topic and give it some input - perhaps your IoT Hub or Service Bus. Then on the other end you create a subscription. For something like an Azure Function this is as easy as clicking “Add Event Grid Subscription” in the top right of the UI. Event Grid can also be managed using Azure CLI tools or PowerShell.
Now let’s say that instead of piping our events to some other system we would rather process them directly to derive useful insights. Here is where Azure Stream Analytics comes in to save the day. If you look at the diagram you can see that, much like Event Grid, Stream Analytics act as as a kind of middleware. It takes streams of event data from Event Hubs or IoT Hub as an input, performs some processing, and then outputs to some downstream consumer.
Exactly what Stream Analytics will do for output will vary based on your business. You might want to save Stream Analytics outputs to a DB for storage or batch jobs. You might push the results to Service Bus, an Azure Function, or even to another Event Hub. It all depends on the type of job you are doing. The key thing that distinguishes Stream Analytics from Event Grid is the ability to visualize and utilize data immediately from the source pipeline. This is helpful when you want to make sense of telemetry data, send alerts based on sensor readings, or trigger some other backend functionality based on a real-time understanding of the data.
So with Event Grid and Stream Analytics we have covered how we can use event data for our purposes by either coupling events with other services or doing real time analytics. But what about if we want to use event data on the client side? How can we do useful work away from the cloud or even just interact with clients and users?
This is where Azure Notification Hubs and IoT Edge come in. The former is ready made smart device notification solution. Need to send push notifications to iPhones, Android phones, or tablets? Notification Hubs is your answer. The great thing about it is that it takes away a lot of the pain involved in supporting a variety of mobile devices. If you have experience as a mobile developer then you’ll really know what I am talking about. Unlike other forms of messaging, push notifications often have tricky platform-dependent logic. Scaling, managing tokens, and routing messages to different segments of users on different hardware and different versions of Android is non-trivial work for even an experienced tech team.
Notification Hub takes away most of that pain. It lets you broadcast to all platforms with a single interface. It can work both in the cloud or on-premises and includes security features like SAS, shared access secrets, and federated authentication. See the “How To” guide link for more details. (https://docs.microsoft.com/en-us/azure/notification-hubs/notification-hubs-aspnet-cross-platform-notification)
Lastly we need to talk about IoT Edge. IoT Edge is a tool for empowering IoT devices. It lets you run code directly on client devices instead of in the cloud. So you can do things like change device configuration, get real-time analytical data, or detect anomalous conditions. The chief value of doing such work directly on the device is that it saves the effort of having to send event data back and forth over the internet. So for example, we might want an IoT home sensor to alert us to some unusual condition without having to phone home to the cloud to run analysis. You can imagine how valuable this could be for something like an IoT smoke detector or security system. IoT Edge can also empower devices where network connectivity is not always reliable.
So how exactly does IoT Edge let you run code on the device itself? It’s pretty ingenious actually. What you do is install an IoT Edge runtime on your client device. This runtime executes IoT Edge modules. These modules are just lightweight Docker containers that run whatever business logic you want. Modules can call other Azure services, run 3rd party software, or execute your own custom code. Whatever it is you need your device to do. The IoT Edge runtime will manage your modules, track module health, facilitate communication with downstream itself and other endpoints, and manage security. Best of all: You can track all of this activity in the Azure web portal. With a few clicks you can monitor device health and push updates or configuration changes. IoT Edge gives you ultimate control over your entire fleet of IoT devices.
IoT Edge does not integrate with Azure Event Hub. To properly make use of IoT Edge you need an IoT Hub account. Note that with the IoT Hub basic tier account, you can only use IoT Edge for testing and evaluation. You need a paid IoT Hub Standard tier account to get proper support for IoT Edge production use cases. As mentioned above this is what enables the cloud-to-device messaging that powers IoT Edge.
So that about wraps it up. We have gone over all of Azure’s offerings in the IoT space. You should know enough now to be dangerous. To really solidify your understanding, play around with some of these tools in the Azure portal or at least read some of the quickstart and how-to guides in the Azure documentation. So for our next section we’re going to offer some additional insight about selecting the right IoT Azure service for your particular use-case. See you there.
About the Author
Jonathan Bethune is a senior technical consultant working with several companies including TopTal, BCG, and Instaclustr. He is an experienced devops specialist, data engineer, and software developer. Jonathan has spent years mastering the art of system automation with a variety of different cloud providers and tools. Before he became an engineer, Jonathan was a musician and teacher in New York City. Jonathan is based in Tokyo where he continues to work in technology and write for various publications in his free time.