Getting started with Azure IoT Edge is easy. Microsoft offers quite some tutorials for several operating systems for setting up an edge gateway.
Once you have created your first IoT edge solution and played with it, you discover Azure IoT Edge takes a bit more time to master.
In real-life IoT is hard, though…
This is because there are more moving parts like security, provisioning, managing, monitoring, etc.
For example, take a look at the ‘iotedge check’ output on your edge device:
This feature of the iotedge runtime makes it possible to check how well your runtime is hardened against common scenarios where something can fail (eg. running out of disk space due to extensive logging or firewall blockades for certain protocols).
In this case, a message is shown which indicates the runtime is using a development (x509) certificate which will expire within ninety days. Communication between the edge modules will stop after that date. A reboot/restart of the runtime is needed to get the runtime running again for another ninety days.
What is the purpose of this certificate and why do we need this to be fixed?
IoT Edge certificates are used by the modules and downstream IoT devices to verify the identity and legitimacy of the IoT Edge hub runtime module
So, apart from the secure connection with the cloud (either with a symmetric key, x509 certificate, or a TPM endorsement), this certificate is used to secure the communication between modules and possible edge devices. If the certificate expires, edge communication comes to a hold.
Let’s check out how to ruggedize the communication.
Azure IoT Edge is based on the concept of modules. A module is a container holding some logic executed on the edge device. These containers are actual Docker containers.
These can both be generic containers like a NodeJS that you have produced yourself, an open-source container, or a commercial container. In can also be a container supporting Azure IoT Edge module twins and the routing between modules using one of the Azure IoT Edge SDKs.
Anyway, the modules have to be deployed at one point in time.
By default, Azure IoT Edge devices are constructed with two basic modules registered, the edgeAgent (which is responsible for life-and-death of other modules) and the edgeHub (for enabling message routing between modules and the local gateway towards the cloud):
With life-or-death of other modules I mean the EdgeAgent is responsible for keeping the module configuration on the Azure IoT Edge device in sync with the registration and configuration in the IoT Hub device registration.
Each time the configuration of an edge device registration in the IoT Hub changes, a new version of the deployment manifest is offered to the Edge Agent. It contains both the module descriptions and their configuration and a description of the message routing on the edge.
The Edge Agent then picks up the deployment manifest and checks for changes with the last manifest it received. If there are any configuration changes, or modules added or modules deleted, the edgeAgent will start the process of synchronizing the deployment.
If you check the documentation, three ways of altering the IoT Edge configuration (and thus deploying a new deployment manifest) are documented:
Azure has all sorts of Publisher/Subscriber resources available to allow sending and receiving messages (events) within Azure. Think of the Service Bus, EventHub, Storage Queue, Stream Analytics, Azure Functions, etc.
At some point, Microsoft realized that a more formal way of the eventing abilities of these resources was needed.
This let to the introduction of the EventGrid, one overall solution to send and receive messages. Azure Event Grid relatively new.
The Azure Event Grid allows you to easily build applications with event-based architectures
The Azure resources are divided into two groups:
Event sources. Resources which produce events (or pass-through events)
Event handlers. Resources which are able to pick up events and do something with them
These resources all come together in the Event Grid.
The Azure IoT Hub can act like an Event Source too. The events exposed are:
Once you start collecting data in an IoT solution, you will need some kind of dashboard to represent the raw or aggregated data.
IoT projects typically start as a POC to validate IoT scenarios. When the POC success, a pilot project is started to check scalability, monitoring, maintainability, etc.
Microsoft provides multiple solutions for these various scenarios. The most lightweight solution is IoT Central.
“Experience the simplicity of SaaS for IoT (Internet of Things), with no cloud expertise required—Azure IoT Central is a fully managed global IoT SaaS (software-as-a-service) solution that makes it easy to connect, monitor, and manage your IoT assets at scale. Bring your connected products to market faster while staying focused on your customers.”
You can start with a 7-day trial or with pay-as-you-go. This last option is free if you limit yourself to 5 actual or simulated devices.