This past March marked the one-year anniversary of the covid-19 pandemic. I found myself reflecting on the changes I’ve gone through, both personally and professionally. One of the bright spots was realizing how much progress our customers have made with Azure IoT Edge and the number of improvements our team has been able to add to the product. Let’s take a moment to celebrate some of the successes in a year that most of us would prefer never happened.
Product maturity
COVID has caused a noticeable change in the types of scenarios in which customers are using Azure IoT Edge; however, it hasn’t dampened the market’s embrace of our product. In the past year, we documented over 25 new case studies of customers using Azure IoT Edge in their digital transformation. While these case studies are a sampling of the many customers using Azure IoT Edge, they are a great example of how widely used our product is. There is representation from a gamut of industries including: automotive, banking, energy, farming, healthcare, HVAC, industrial automation, manufacturing, packaging, real estate, recycling, retail, and shipping.
Azure IoT Edge hit an important milestone in March with the 1.1.0 release. It is our first long term servicing (LTS) release and will only be serviced with fixes to critical security issues and regressions. All other bug fixes and new feature work goes into our rolling feature releases (1.2.0 and greater). The limited number of changes in makes 1.1.0 it our most stable release and ideal for extended periods of use in production.
Security
Notable security exploits and data breaches continued in the tech industry last year. Azure IoT is a leader in edge security; however, we realize that we cannot rest on our laurels. To that end, we’ve shipped features specifically intended to increase the security posture of Azure IoT Edge.
First, we’ve updated the runtime to acquire needed certificates from EST standard infrastructure. Some customers require that certs come from their on-prem PKI infrastructure and leveraging the EST standard allows the product to integrate with compatible infrastructure.
Simply allowing customers to create their own certs is not enough. These certs must be protected from tampering, or theft, once on the device. Azure IoT Edge now uses the EST standard to integrate with hardware security modules (eg. TPM) to protect these valuable certs.
Just because a device starts off secure does not mean it remains secure. New vulnerabilities are discovered daily. Updating devices is a critical capability in the quest to keep assets protected from the latest threats. IoT Edge already does a great job of allowing customers to update the workload running on a device; however, patching the OS or even updating native components of the runtime was a job left up to the user. No more! Device Update for IoT Hub is in public preview. Customers can update IoT Edge devices, use an IoT Edge device as an update cache for downstream devices, and all of this works in a nested hierarchy often found in ISA 95 networks.
Observability
The ability to remotely monitor devices, understand how they are operating, and proactively identify problems is critical for solutions running in production. The IoT Edge runtime is now instrumented to produce metrics like resource consumption, message throughput, and module uptime. There’s a private preview detailing how customers can harvest these metrics and send them to the cloud to create intuitive dashboards, and we’re already working on making this default functionality you get out of the box.
The support experience has also been improved. Once you realize there is an issue which needs more investigation, customers must collect logs from various components and upload them to the cloud. Now the runtime is smart enough to automatically collect the pertinent logs and upload them on the customer’s behalf via the support-bundle command.
Industrial
Over a year ago we undertook a feature set aimed at unblocking industrial customers. We’re now starting to see the benefits of that work. Many industrial customers have ISA 95 networks, a standard that creates a hierarchical topology where networks are layered on top of each other. Devices in one layer can only talk to devices in the previous or subsequent layer. This throws a wrench in IoT Edge solutions because the IoT Edge devices cannot send telemetry, receive updates, or do anything else that requires the internet unless they are in the topmost layer.
IoT Edge in a nested configuration allows customers to create a daisy chain of IoT Edge devices that traverses the network hierarchy. The devices in isolated network levels leverage the connection of their parent to eventually gain access to the internet.
Nesting of IoT Edge devices doesn’t only solve the industrial problem of ISA 95 networks, it’s useful for any customer who wants to run analytics in any type of hierarchy. For example, a customer in smart buildings could use nested edge for granular optimization of energy usage. An IoT Edge device could be used to run a machine learning model which optimizes energy usage for a single floor. This device could then supply data to a parent IoT Edge device which is running AI that optimizes energy usage for the entire building.
Edge analytics
Digital transformation has multiple phases: Connect & Monitor, Analyze & Improve, Transform & Expand. While many customers are still working through the first phase, there are others who have graduated to running analytics on the edge. Azure IoT Edge continues to invest in this area so that we have powerful features available when customers are ready to leverage them. For example, the LTS branch of IoT Edge supports native integration with Nvidia deepstream so that customers can create devices which score AI models on multiple video streams in real time!
The development story for edge analytics is also being moved forwards in leaps and bounds. Recently the Percept family of products was announced. These are best in class dev kits which are built on Azure IoT Edge.
MQTT
We have heard the desire for an MQTT broker that supports customer defined topics, pub/sub semantics, and existing MQTT devices. Azure IoT Hub and Azure IoT Edge are working together to provide this capability in the cloud and on the edge. The beginning of this functionality is available on the edge in a public preview.
Azure IoT Edge on Windows
Windows has a long history of security and best in class manageability. These are key reasons that some customers want to run Azure IoT Edge on a Windows host machine. Unfortunately, using these two products together create issues which are not present when running Azure IoT Edge on Linux. For example, the base image of Azure IoT Edge modules must match the Windows host OS image and RS5 was the only supported OS. Or, partners had to maintain two versions of their modules, both a Linux container and Windows container, to target all Azure IoT Edge devices.
Azure IoT Edge For Linux On Windows, a technology in public preview, fixes these issues. It transparently spins up a Linux VM and runs Azure IoT Edge in the context of this Linux VM. Since the VM is transparent, customers continue to manage the Windows host as they would any other Windows device. Partners writing modules for Azure IoT Edge now only have to create and maintain Linux container versions of their modules since Azure IoT Edge now runs in a Linux environment, regardless of the OS used by the host.
Supporting features
The very large investments detailed above should not overshadow a handful of smaller point improvements that add critical functionality to Azure IoT Edge solutions.
- Message priority ensures that high priority messages are synced to the cloud before lower priority messages after a period of no connectivity.
- Module boot order provides information to the runtime used to try and start modules in a particular order. Please note, that this order is not binding (a module which is started first may take a while to initialize and a subsequent module could begin running before it). Module boot order also does not apply to restarts of individual modules (if the first module crashes, all subsequent modules continue to run and are not restarted with the failed module).
- Module twins now support arrays. This provides module authors to more data structures for syncing information in module twins and prevents them from (serializing/deserializing) arrays (into/out of) module twins.
The work produced by the IoT Edge team over the past year is nothing short of amazing. It’s even more impressive when one realizes that it was delivered under such stressful conditions. Lorenzo and I are truly grateful to lead such a talented and motivated team. Working with them has been a highlight in a year where so many people have struggled. We have many more great innovations coming this year, and we can’t wait to see the solutions our customers continue to build with Azure IoT Edge.