Microsoft’s Azure IoT Edge was announced at Build 2017 to much fanfare. The idea goes that the edges of a network are underutilized and devices are unnecessarily chatty with the cloud. Wouldn’t it be great if you could move some of the work being done in the cloud down to your device? That’s where Microsoft’s Azure IoT Edge comes in.
The example given at the Build highlighted work done with Sandvik Coromant, a manufacturing tools company that creates multi-million dollar machines. Before IoT Edge, Sandvik Coromant utilized the Azure’s Stream Analytics and Machine Learning platforms to predict disasters and shut down machines if one seemed pending.
There’s only one problem: communication to the cloud introduced a two-second latency and time is of the essence when it comes to an emergency shutdown. By utilizing IoT Edge, Sandvik Coromant was able to take the same logic used in the cloud and move it to the edge, reducing latency to 1/10th of a second.
There are many potential advantages to moving compute from the cloud to the edge; reducing latency is but one. Reducing bandwidth costs, simplifying development by using the same programming models in the cloud as on your devices, allowing the use of Azure’s advanced cloud platform locally, the list goes on. For some work, IoT Edge seems like a fantastic tool.
But does reality live up to the hype? Let’s delve in a little deeper.
After some investigation, I was surprised to find that Azure IoT Edge was not a completely new product. It’s a new name to reflect all of the new features that have been packed into an existing product, Azure IoT Gateway SDK.
Although I felt a little duped at first, I understand Microsoft’s reasoning. If anything else, Azure IoT Edge is a sexier name, so let’s just roll with it. Azure IoT Edge does everything that Azure IoT Gateway SDK did, and more. So other than moving compute from the cloud, what does this thing do?
Azure IoT Edge’s primary objective is connecting existing industrial devices to the cloud and each other; making previously dumb machines smarter and more connected.
Getting Started with Azure IoT Edge
As a C#-loving .NET developer at heart, I decided to grab the latest and greatest .NET Standard module sample to get started. After following the instructions to download the sample app, I attempted to run it to no avail. “The debug executable…specified in the debug profile does not exist.”
Hooray! I had a (fake) sensor throwing some stuff at IoT Edge. But really, what was that doing? There was no cloud involved, no models I had created in Azure and put on my local device. I had to dig deeper.
IoT Edge “Hello World”
Taking a different tack to learn a bit more, rather than running the standalone samples I decided to get the source for IoT Edge. Interestingly, the source for IoT Edge itself contains additional samples. I would have liked to see the main GitHub repository contain the source of IoT Edge without any samples, or just lump everything together into one repo. Having multiple repos with samples confuses the issue, I think.
I found the Microsoft documentation on Azure IoT Edge helped clarify things and I was able to getting up and running with the “Hello World” sample.
I installed the prerequisites as instructed to build IoT Edge from source, which includes installing CMake and Python 2.7 and making sure the folders in which they reside were added to the PATH environment variable.
Then, I ran the command
tools\build.cmd --disable-native-remote-modules to build the sample in the Developer Command Prompt, opened through Visual Studio. Don’t be like me; make sure you have “Desktop environment with C++” installed through the Visual Studio Installer even if that’s not your development bread-and-butter. You’ll need that.
After digging into the documentation a bit, I understood a bit more about how this thing works. You can imagine it as a mini operating system, with “modules” standing in as apps.
Following the instructions to create the “Hello World” sample, I found it utilizes a JSON configuration file. In this file, you indicate the modules you want to use and their entry point as well as any static arguments you will be needing.
It seems like a straightforward system of setting up configuration variables, especially useful for tying together a bunch of modules you don’t own. For the “Hello World” sample, it uses two modules: “Hello World” and “Logger.”
The idea is that the Hello World module just prints some messages to the Logger, whose only role is to output these messages into a file. Extrapolating out, it’s obvious the Logger module could be used by any other module you decide to create.
To run the sample, all one needs to do is enter
samples\hello_world\Debug\hello_world_sample.exe ..\samples\hello_world\src\hello_world_win.json into any old command prompt. This starts the sample executable and points it to use the included default JSON configuration file. Then, Azure IoT Edge starts, runs the modules, and starts logging a “Hello World” message to the file specified in the JSON config file every five seconds.
Can we edit this module to do our bidding?
The out-of-the-box configuration writes to a
iot-edge/build/log.txt file. I wanted to test that changing the configuration file (located at
iot-edge/samples/hello_world/src/hello_world_win.json) would change the output. After updating it to write to a
.json file, it was in JSON format after all, I ran the Hello World sample. Yep, it logs to a bonafide JSON file now!
To Be Continued…
Seeing the promise of Azure IoT Edge and getting a handle on how to start and run a sample application is a start, but I want to dive deeper. In Part Two I’ll be diving deeper into implementing the Azure IoT Edge process as well as exploring how to connect IoT Edge to the cloud and simulate a device.