We briefly touched edge compute solutions in the previous articles. But what is IoT Edge exactly?
Let’s say you have an amazing solution and the hardware that can process content locally before sending it to the cloud. Perhaps you want to do image recognition or process a video stream and use some machine learning components to achieve that. It makes no sense to have hundreds of devices send forward the stream to Azure and then process it. This will result in a lot of traffic and might require some expensive Azure components to process it swiftly. If you have the capabilities on your device then IoT edge is the solution you want to look into.
If you want to get started I highly recommend using a raspberry PI or if you’re feeling adventurous and really want to play with the AI and machine learning stuff an Nvidia Jetson Nano Developer Kit
The IoT Edge components
First thing you want to do is install IoT edge on your device. If you are keen to test it out first you can also run it on your local system. After installing IoT Edge you basically have three components:
IoT Edge modules which are containers that run your own code or third party solutions
IoT Edge Runtime which manages the modules
Cloud-based interface for monitoring and remotely managing your device(s)
All these components run in containers on the edge device. Just like the regular IoT devices we discussed in the previous articles, IoT Edge devices can connect directly to IoT Hub and you can manage them on a per device basis or in groups.
The modules are where the magic happens. These contain your code, machine learning models and other logic you need for processing the data. The modules (containers) can be configured to interact with each other. For example: my test setup consists of a Nvidia Jetson Nano that runs a module which captures an RTSP stream from a camera I situated in the house. Another module contains the machine learning model for classification and sends the results to IoT Hub.
Once your device is connected to IoT Hub you can manage the modules from IoT Hub itself as explained here. You can even deploy modules at scale across all your devices. For this we need tags and the Device Twin (more on this in the next blog post).
But maybe you’re not writing all the stuff yourself and you want to leverage some third party solutions. And there are quite some third party modules readily available on the Azure Market Place. Ranging from modules for Real Time Video analytics to the simulated temperature sensor developed by Microsoft. Even if you don’t need that exact module, it is a good idea to test it out, inspect it and see how you can maybe build on top of that.
Using IoT Edge as a gateway
We also discussed using an IoT Edge gateway in previous articles. There are big use cases for using the IoT Edge gateway. A good example is running devices locally that are not supported by IoT Hub. As we discussed, IoT Hub only supports MQTT, AMQP and HTTP. But.. What if you are running devices that use the Modbus protocol and you still want to use Azure IoT Hub? No worries. As mentioned you can write your own modules for IoT Edge devices. This means you can write a module that accepts any type of data from the local network, process it and then send it to IoT Hub. The possibilities are literally endless. If we look at the Modbus example there is a module readily available for that here: Azure/iot-edge-modbus: Modbus protocol module for use with the Azure IoT Edge (github.com). Basically what will happen is the following: a container (module) will spin up that reads data from the Modbus devices and transform it into the supported AMQP format. But you can pull the image apart and tailor it to your needs if you want to.
Additionally you can use IoT Edge as a gateway for devices that needs to be configure in a hierarchical order. Let’s say you have one IoT Edge device that is connected directly to IoT Hub and you have multiple IoT Edge devices that gather telemetry. You can configure those devices to send the telemetry to the IoT Edge device that acts as a gateway and sends it to IoT Hub. We’ll call this a “parent – child” configuration. It’s not a next-next-next finish set up but once you have your certificates (PKI) in place and configured the downstream devices you have a pretty solid solution that can easily be maintained. If you’re keen to try it out please check this tutorial.
Confidential Computing with IoT Edge
Where you can configure security on many levels for IoT Edge with certificates, secured connections and overall good configuration of your message routing.. There is also a really cool feature that is supported on IoT Edge: Confidential Computing. It’s not the easiest technology to grasp the concept of but it provides amazing security. Apart from the IoT Security manager that uses an Hardware Security Module (HSM) to protect the workloads and processes it also focusses on protecting data at runtime. For this it uses a Trusted Execution Environment (an isolated environment in the processor). Basically what is happening is that your App (a confidential application) runs in this Trusted Execution Environment where it is secured from all other processes running on the processor.
This does require some development effort. By creating a confidential application you are essentially encryption your application. These confidential applications are now encrypted in transit and at rest even in the Azure Container Registry (remember we’re still talking about modules). Only after deployment and during startup the application is decrypted within the Trusted Execution Environment. And within that Trusted Execution Environment, nothing can touch it as this is separated from all other processes.
Confidential computing is not just limited to IoT Edge and certainly this little paragraph does not do it all the justice it deserves but I still wanted to mention that if you want to go down this path, it is definitely possible. If you want to know more about confidential computing on Azure in general please check this link.
And with that, we’re at the end of our IoT Edge article. In our next post we’ll go further down the rabbit hole and look at using Device Twins to manage devices, which is easier than it sounds but also an amazing technology!