Review: Azure brings IoT to .Net developers

Technology trends don’t come more nebulous than the “Internet of things.” After all, a thing can be anything. For developers wanting to get past fuzzy concept to real code, Microsoft’s Azure cloud is a fine place to start. Like Amazon’s AWS IoT, the Azure IoT Suite pairs back-end services with SDKs for low-power client devices such as the Raspberry Pi. Unlike AWS IoT, Azure supports .Net development as part of the mix.

The Azure IoT Suite, which includes the Azure IoT Hub and other services, can help you to generate solutions from common templates. Once you’ve generated a provisioned IoT solution, you can connect it to real devices and modify it as needed.

The Azure IoT Hub is a service for controlling and ingesting data from IoT devices, typically single-board computers such as the Raspberry Pi, which are in turn connected to sensors, relays, and ultimately real-world machines ranging from “smart” lightbulbs to automobiles, manufacturing plants, and entire cities. The Azure IoT Hub can connect to a number of other Azure services to build a complete IoT solution.

The Azure IoT Hub Client SDKs allow you to actually connect to devices. The SDKs are all open source and updated frequently. At the time of this writing, Azure’s list of certified IoT devices includes more than 50 boards. According to the installation documentation in the repository, more single-board computers are currently supported than are listed. For example, the C SDK contains installation instructions for an Arduino Yún.

Right now, the only development environments explicitly supported by the C and Java SDKs are Windows and Ubuntu. The .Net SDK, unsurprisingly, only supports a Windows development environment, and the documentation says, “You can use any version of Visual Studio 2015, including the Community edition.” The Node.js SDK documentation only talks about setup for Windows and Linux; I wouldn’t be surprised if the Linux instructions were substantially correct for Mac OS X as well.

Client SDKs and devices

I used an early version of the C#/.Net SDK at last year’s Build conference, with a laptop running Visual Studio 2015 as the development environment and a Raspberry Pi 2 client running Windows 10 IoT Core connected to a toy robot car. In that environment, with everything already configured, a hands-on exercise laid out, and live in-person help readily available, it was all quite simple.

You can theoretically buy a Windows 10 IoT for Raspberry Pi Starter Kit that provides a preconfigured SD card and the official supported Wi-Fi dongle. I bought a different Raspberry Pi 2 kit, as the Windows IoT kit was out of stock. Mine came with a microSD card loaded with the NOOBS (New Out of the Box Software) installer and a less expensive Wi-Fi dongle that (ahem) isn’t currently supported by Windows 10 IoT Core, so I installed Raspbian from NOOBS and got the Pi working on my network. The Raspbian client is supported by the C, Node, and Java SDKs, but not the C#/.Net SDK. (I was planning to download the Windows 10 IoT image and burn it onto another microSD card so that I could use the C#/.Net device SDK with Visual Studio, but I didn’t get the required official Raspberry Pi Wi-Fi dongle in time.)

Although OS X isn’t among the supported development environments, after reading the code I think I can adapt the Ubuntu setup for all three SDKs to work on OS X with some effort. I also have Windows 10 and Visual Studio 2015 installed on an HP Spectre 360, along with an Ubuntu x64 VM that I can run on VMware Fusion, both of which are supported development environments for some of the device SDKs.

I also bought an Arduino Yún, which seemed like the easiest way to test the AWS IoT SDKs. Reading the code for the Arduino Yún Ubuntu installer in the Azure IoT C device SDK, I also think I can adapt it to work on OS X. It might not even be hard to do.

The BeagleBone, Intel Edison, Freescale FRDM-K64, and Texas Instruments CC3200 are also officially supported by the Azure IoT Suite. I’ll take it on faith that the SDKs for those boards work as documented, especially since I’ve watched videos where some of the Microsoft Program Managers did demos with them.

Beyond the big issue of setting up your device with the right drivers, there’s an issue of cross-compilation, at least for C. The Raspberry Pi 2, a 900MHz quad-core ARM Cortex-A7 CPU with 1GB of RAM, can actually compile and link C code itself, but it is much, much slower than cross-compiling on a 2.8GHz Intel Core i7 with 16GB of RAM. Visual Studio 2015 takes care of this itself, with a nice GUI. It wasn’t too hard for me to find the switches needed to cross-compile for ARM from Clang on a Mac, although I had to dig around on the Internet. The Arduino Yún development environment for the Mac does its own compilation, then downloads the binary to the device over Wi-Fi or a USB connection.

If you’re confused by the absence of Mac support, join the club. It’s too bad that Microsoft hasn’t yet tested and supported an OS X development environment for Azure IoT devices. After all, most of the technology is there, and IoT back-end competitor Amazon supports OS X as a development environment.

I realize that the Azure IoT team has a lot on its plate, however, and it’s clear that several of the services shown in the diagrams have not yet been released. It is also working on a Python device SDK, but hasn’t promised a delivery date.

Nevertheless, the actual device programming is not terribly complicated. You set up the device to send status messages and handle commands. There are straightforward APIs to do everything you need to accomplish.

Management, protocols, and analytics

Microsoft provides a nice Web management console for the IoT Hub, as shown in Figure 1. It can actually get down to the device level and send commands, but that of course won’t scale to thousands or millions of devices.

In addition to the Web management console, you can (in Windows) manage the Azure IoT Hub from Visual Studio 2015 with the current Azure plug-ins installed, and from PowerShell once you add the Azure PowerShell Resource Manager and Service Manager modules. On any platform, you can install and use the Azure CLI. If you want a scalable way to, say, connect thousands of devices, you can either write shell scripts or program against the Azure IoT APIs for REST (using any language or platform) or .Net.

For devices that can connect to a TCP/IP network, Microsoft supports HTTPS and the more efficient Advanced Message Queuing Protocol (AMQP) natively, and the MQTT protocol (which is what AWS IoT uses) through a protocol gateway. For devices that use a nonroutable local network such as ZigBee, you would need to pass the messages through a field gateway to convert them to and from AMQP. Unfortunately, the field gateway code hasn’t yet been released.

One thing I’ve noticed about designing an actual application around the Azure IoT Hub is that it requires a lot of moving parts, enough to be a pain to configure. There is a shortcut, however: provisioned IoT solution templates, which set up the entire range of Azure services along with some simulated devices. Once the solution is provisioned, you can add and subtract services and clients as needed.

There are currently two provisioned IoT solution templates: one for monitoring (Figure 2) and one for predictive maintenance. The latter is more useful, but rather specialized; it also requires real-time monitoring in advance as well as quite a bit of event logging, data analysis, model building, and model tuning. As I learned firsthand many years ago when automating a cyclotron, even systems for which exact equations exist will exhibit unexpected behaviors that need to be added to the model, and that takes time and bitter experience.

In addition to Azure Stream Analytics, Azure IoT typically stores data in blobs. These can be analyzed using HDInsight and Machine Learning, then fed into Power BI for additional analysis, both routine and ad hoc.

Overall, there’s a lot to like in Azure IoT. While it’s usable for many applications in its current state, several pieces are still missing, including the field gateway intermediary, which will eventually allow groups of devices working over ZigBee, Z-Wave, Insteon, or Bluetooth Low Energy to send data to the IoT Hub and accept commands from the IoT Hub. At least Microsoft is talking about this need; I haven’t yet heard AWS announce any plans for non-IP-connected devices.

If you compare the scores in my Azure IoT and AWS IoT reviews, you’ll discover that they are identical in every category. There are certainly differences between the two services, but not a full point’s worth -- and we round our scores to integers.

In the area of value, I find it very hard to predict relative costs between the two platforms. AWS IoT charges per million messages in and out; Azure IoT has a tiered rate system that depends on the number of devices as well as the volume of messages. In either case there are a half-dozen other services that you are likely to use as part of your solution, all of which have their own costs.

At this point, there isn’t a clear winner. I’m not sure there ever will be, but there are certainly differences between the two approaches, and one may be closer to your needs, skills, and preferences than the other.

Microsoft’s support for .Net development and bias against Mac development environments are two clear differences. There’s also an architectural difference. AWS IoT uses device shadows, certificate-based authentication, and the MQTT protocol, all of which suit simpler clients. With Azure’s preference for the AMQP protocol and use of SAS tokens for client authentication, it is more oriented toward the Raspberry Pi 2 or Intel Edison than, say, an Arduino Mini.