The Microsoft IoT Quick Guide

Microsoft has a bunch of tools labeled “IoT.” What are their similarities and differences? Why would you choose to use one over another (and do they play nicely together)? Let’s find out.

Azure IoT Hub

A connection from Azure to the device and vice versa without worrying as much about how to do so securely and reliably.

Pros: Lightweight, secure, reliable connection between device, cloud, and vice versa with SDKs for C, Java, Node, and .NET.

Cons: Few. This is the primary recommended way to communicate between devices and Azure.

When To Use: When you don’t want to reinvent the wheel for how to communicate securely and reliably between Azure and devices.

Use With: Azure IoT Edge, Windows 10 IoT Core, Windows 10 IoT Enterprise.

Azure IoT Edge

For when you want to take data from many sensors, process it locally, and send important stuff to the cloud.

Pros: Runs on Linux or Windows, open source, consists of modules that can be written in many languages and mixed and matched, runs some Azure services at the edge.

Cons: A somewhat complex solution.

When To Use: When you have a bunch of sensors, especially old ones, that you want to connect to the cloud. Factories are a perfect use case.

Use With: Windows 10 IoT Core on x86 devices, Azure IoT Hub.

Azure IoT Suite

A wizard walks you through the creation of a bunch of Azure services and code running on them. Use it to quickly bootstrap a fully featured IoT solution as a head start for your project.

Pros: Much, much faster than doing everything from scratch.

Cons: Can be complex and expensive for a proof-of-concept phase.

When To Use: When you are ready and funded to build your IoT solution with Azure and want to save three months of time figuring out how to architect it.

Use With: Azure IoT Edge, Windows 10 IoT Core, Azure IoT Hub.

Windows 10 IoT Core

The free, lightweight, yet completely serious Windows operating system for IoT devices.

Pros: Perfect for running a single UWP app.

Cons: Requires relatively hefty hardware (at least for IoT) and only runs Windows UWP apps.

When To Use: Kiosks are a great use case. Also could work as a small gateway or in consumer devices that can plug into the wall.

Use With: Azure IoT Edge on x86 devices, Azure IoT Hub.

Windows 10 IoT Enterprise

The not free and full-fat Windows operating system for IoT devices. This is exactly the same operating system as Windows 10 Enterprise, licensed for IoT use.

Pros: Full Windows allows for maximum flexibility.

Cons: Requires x86 processor and also more management know-how than Windows 10 IoT Core.

When To Use: When Windows 10 IoT Core is not enough.

Use With: Azure IoT Edge, Azure IoT Hub.

Azure IoT Central

The Software-as-a-Service for IoT. This is the no-code solution to getting up and running with IoT in the cloud.

Pros: Much of the groundwork done for you and abstracted away.

Cons: Not yet fully featured, little integration with other services, APIs aren’t open to developers.

When To Use: When you want to bootstrap something quickly, have little internal IoT experience, and all you need is a few dashboards and email alerts for your IoT product or service.

Use With: Doesn’t play nicely with much else yet. Stay tuned for integration with Azure Functions and Logic Apps, which will open a floodgate of integration possibilities.

Azure Sphere

The answer for securing and connecting tiny microcontroller devices, including a custom Linux operating system, hardware reference designs, and the cloud.

Pros: A cohesive solution for connecting low-power microcontrollers.

Cons: Specific to low-power devices.

When To Use: When you want an all-inclusive solution for connecting microcontrollers, like those in refrigerators and garage door openers, to the cloud.

Use With: Other services in Azure.

But Wait, There’s More!

There are many other services offered by Microsoft without IoT seared into their title that play nicely with the Internet of Things. If you have any questions or thoughts on those other services, don’t hesitate to reach out to me on Twitter @jporcenaluk!

1,000 Year Old Software

It was only 80 years ago that the first electronic digital computer was built, the Atanasoff-Berry Computer in 1937. And that was the first. Now, computers outnumber humans and the rate of innovation is increasing exponentially. To expect any technology from today to last more than a few decades is foolish. Technology is moving faster and more unpredictably than ever. On top of all that, we are creating technology that is build to be thrown away. The first-generation iPhone, now only ten years old, is but a curiosity. The rapid pace of innovation means that your hand-held wonder-brick you stood in line for is on a two-year upgrade cycle. At five years old, your computer is ready to be tossed. They keyboard I’m typing this on will likely be in a landfill by the time I end this sentence.

Ok, maybe it’s not that bad. But what hope do we have that in a thousand years any software, any line of code, any work that we’ve done today will still be used in any capacity whatsoever?

On a trip to Italy last summer I was astounded at the wonders of the ancient world. The Colosseum was completed in 79 A.D. The Pantheon? Construction started in 27 B.C., over two thousand years ago. These analog stone structures, sitting out in the rain and snow and hail, through generations and wars and changes of religions, are still there. The Pantheon looks like it’s ready for two millennia more. And these structures are huge. The Pantheon’s dome is wider than that of the Capitol dome in D.C.

Twenty-eight of panels like this form a fifteen-foot-high door. Image found at http://tuscantraveler.com

Artists of the renaissance, painters and sculptors, would often start work that would take decades to finish. They often didn’t know if they would see the completed project. I wonder what the likes of Lorenzo Ghiberti, who took twenty-seven years to complete a set of bronze doors for the Florence Baptistery (Battistero di San Giovanni) would think of the concept of a Minimum Viable Product.

Still, there are legends and war stories about pieces of code or whole programs that last. “Good code never dies” is a stalwart tech industry saying, and there are legions of software engineers toiling away on COBOL and Fortran to prove it. A software program used by the DOD is over fifty years old and still going. For all the innovation in computing, some of the same basic principles have remained. Binary, the zeroes and ones represented a first by mechanical methods and later by electrical means, seems to be a sticky concept. It’s an open question as to whether quantum computers, which represent data in several states at once, will usurp the mathematically simple building blocks of binary. Maybe long after that happens, the oldest code of all will live on in one of the Voyager space probes, blinking into existence thousands of years into the future.

Perhaps contemplating the oldest software is a fool’s errand, and we technologists have never been about putting our works behind glass anyway. Preservation has never been our strong suite. We’ve pushed, and pulled, and drug humanity out of the confines of analog and into a dreamy landscape of infinite possibilities. We look forward. These vast ancient structures have not sat in a vacuum, they’ve slowly crumbled and been looted and deteriorated by the sands of time, they’re original purpose put far behind them, they stand as a reminder of who we once were.

The more remarkable feat our fore-bearers did was spread knowledge and progress. We marvel at their works, as they offer markers to indicate what the highest form of our capabilities were at a single point in time. It’s the cultural knowledge that has carried us into modernity. It’s what we’ve learned from them, and their children, and their children’s children that is their true legacy, not bronze and bricks. And our legacy will be the same. It is what we are building right now, the knowledge we are sharing. Our legacy is the outcome of the code we’re writing this very moment in time that is, nudge by nudge, helping shape the world around us to provide a better future.

Those original iPhones have been thrown away, that’s true. The text messages announcing pregnancies, those emails to loved ones thousands of miles away, the inside joke that was shared by two friends in class – that is the legacy of our technology. Although not everything we build creates lasting worth, I would argue we should strive for that. This is our heritage as software developers, not any individual piece of code we protect as it crumbles. It’s the knowledge we share, the code that is used, reused, and modified beyond recognition. The inheritance our software leaves will not be static, it will be alive, and it will stand on the shoulders of giants that stood before.

Those ancient Roman monuments will exist in another thousand years, and we’ll visit them, but we’ll live in a world created by progress.