IoT Edge v1.1 EoL: What does that mean for me?

Microsoft

Oct 27, 2022

Introduction

IoT Edge was released about four years ago and the 1.1 version of it will go out of support in December 2022. Depending on which version of the IoT Edge runtime you are using (Windows or Linux container), there are different recommended actions for you to move to a supported version.

For anyone using the Linux version of IoT Edge 1.1 you will want to upgrade to keep support and to be able to take advantage of extra capabilities that the new version brings. See this announcement for details and links to more information on the 1.4 release.

For customers using the Windows container version of IoT Edge 1.1, know this version is being retired and you need to plan to replace it. But don't panic, whilst the capability to use Windows containers in IoT Edge will no longer be supported, it will still work. Retirement means no further updates or patches will be provided for the IoT Edge runtime. Of course, the operating system it runs on will.

The remainder of this post is going to focus on the primary options to consider when migrating IoT Edge 1.1 for Windows implementations onto other supported applications.

Disclaimer

This blog is unable to cover every scenario and as such has been written to handle what are hopefully the bulk of use cases where IoT Edge is being used as a fairly simple gateway. The main patterns involved here are Transparent Gateways and Protocol Translation Gateways.

Options Flowchart

The flowchart below is intended to give guidance as to the options available depending on your scenario. Each option is discussed in more detail further down this article. If you end up at the “Review Implementation with Microsoft Account Team” endpoint, again Don’t Panic. We have experts who can look at your scenario in detail and suggest the best options. Just because this document doesn’t cover these options, it does not mean that they don’t exist.

Knowing your options

If your IoT Edge implementation is running containers other than the default Edge Hub and Edge Agent, knowing the base image of these containers is a good indicator of which options are likely to be available to you.

If the container uses the NanoServer base image then the workload is very likely based on .NET Core, where the code could be recompiled and packaged as a Linux container and potentially deployed using Edge for Linux on Windows (EFLOW) - a means to manage and run a Linux based IoT Edge instance without having the overhead of having to maintain a Linux environment.

If the container is using a Windows Client or Server Container base image it is more likely that the workload requires the full .NET Framework or other piece of the full Win32 API surface and in this case, you would need to determine if you should run the .NET Framework-based workload as a Windows app or service on the Windows host running EFLOW or re-factor the container to be run stand-alone within a Kubernetes environment.

Knowledge of the work the container is doing will also help. If doing protocol translation for either OSI Pi or OPC-DA, there is a dependency on .NET Framework. Code for other industrial protocol translations such as OPC-UA, MODBUS or BacNet can be run in native Linux environments so can be containerized to run either in IoT Edge on Native Linux or under EFLOW. It is worth pointing out that there is a selection of pre-built modules for industrial protocol translation (and other capabilities) available on the IoT Edge Marketplace.

Options

Let’s examine these options in detail...

1. Azure IoT Edge for Linux on Windows (EFLOW)

EFLOW : Azure IoT Edge For Linux on Windows is a means to run IoT Edge from a Windows machine. IoT Edge runs within a Linux VM on the Windows host. The Linux O/S is of a distribution called CBL-Mariner Linux which is managed and maintained by Microsoft. Patches and updates to both the Linux VM and the IoT Edge instance are managed through Windows Update. The gain here, is that you get an instance of IoT Edge running on Linux without the overhead of having to manage the Linux operating system.

Further details on EFLOW can be found here. Much of the configuration of the IoT Edge can be performed from a PowerShell environment. This page is a list of all of the PowerShell commands for EFLOW. There are also some utility scripts for automating tasks like deploying CA certificates and a script for automating the EFLOW deployment.

With EFLOW, the whole is greater than the sum of its parts. Combining a Windows application and Linux application on the same device unlocks new experiences and scenarios that otherwise wouldn't have been possible. Interoperability and hardware passthrough capabilities built into EFLOW including, TPM passthrough, HW acceleration, Camera passthrough, Serial passthrough, and more, allow you to take advantage of both Linux and Windows environments.

Again, as for option 1, this option is intended for situations where you are running IoT Edge as a simple transparent gateway. If you had some custom containers which either did protocol translation or processed the data before sending to IoT Hub and these containers do not have any hard dependencies on a Windows environment, then these could be ported to Linux containers and run within the EFLOW IoT Edge instance.

2. EFLOW with External Windows Application

In some cases, IoT Edge for Windows was being used because there was a code dependency that meant that Windows was the ONLY choice. A good example of this being the AF SDK for OSI Pi. Despite many requests to the creators, this SDK is still Windows only. Customers who implemented a Windows Container to do the translation work, can re-use the majority of that code as a Windows IoT Device application that resides on the EFLOW Host Windows machine and acts as a sending data to IoT Hub via the IoT Edge within the Mariner Linux VM.

For details on how to configure IoT Edge with leaf devices, refer to either this MSLearn document or this blog post. There are a few items within the original code that will require amendment:

The new application will need to use the IoT Device SDK, rather than the Module SDK
Any module twins used to control or configure the module behaviour will need to be updated to be device twins.
Each instance of the application will need a DeviceID and some form of authentication (X509, SAS Token) to connect to IoT Hub.

If the EFLOW Windows host is Arc managed, the windows application can be deployed and updated via Arc scripting, especially if the code is packaged as an MSIX. For an overview of using Azure Arc and custom scripts to update an Arc connected VM, see this MSLearn article. Note that not all versions of Windows currently support the custom script extensions, see here for the list of supported versions.

A more detailed blog describing the process for setting up this model in a basic form on an Azure VM (no Arc) can be found here.

3. IoT Edge on Native Linux

If your Windows IoT Edge instance is acting as a transparent gateway and only uses the default Edge Agent and Edge Hub containers to process data. Or if your custom container(s) have no hard dependency on a Windows environment, then a direct swap to IoT Edge hosted on a Linux environment is a possibility.

This option is only recommended in an environment where the team supporting the IoT Edge implementation have the necessary Linux experience and skills to manage the Linux device, hardening where necessary and maintaining it with updates and patches as required.

To achieve this:

Set up a test environment with an IoT Hub
Obtain a suitable Linux machine or VM, for a list of supported Linux O/S see here
Install IoT Edge 1.4 LTS following the steps here.
If required test that messages can reach IoT Hub using the Simulated Temperature sensor from the IoT Edge Marketplace.
If using IoT Edge as a transparent gateway, link a test “leaf” device and ensure data flows as expected. You may find this article useful for setting up certificates for the leaf device.
Develop procedures for O/S hardening and patching as required
When ready replace the Windows IoT Edge with the Linux one, you can keep the same device ID as long as you don’t run the two devices concurrently, it is recommended that if using SAS keys that you roll them at this time.
Uninstall IoT Edge from Windows machine ensuring all authentication data (SAS keys, certificates) are removed.

4. Run Windows Container in Kubernetes

Azure Kubernetes Service (AKS) supports Windows Server Container Images. If the custom container that has been running in IoT Edge can be refactored to run as a stand-alone container in AKS lite (currently in private preview) then this option is possible, although there are a couple of dependencies:

The container will need network access both to the source data and also to IoT Hub. If the data source has previously made the connection to IoT Edge and pushed data, then the container will ideally need a static IP address and appropriate network routing in place. If data has been “pulled” from the data source, this is a slightly simpler set up.
The container will need to be re-written using the Azure IoT Device SDK rather than the Module one.
Any control parameters using Module Twins will need to be refactored to Device Twins.
Each instance of the container will need a DeviceID and some form of authentication (X509, SAS Token) to connect to IoT Hub.