One of my university professors once said that “Software is the most complex creation of man.”
I think I’m drawn to software development and to technology in general precisely because it’s complex. It’s a field I know I’ll never reach the extents of. It will never run up against boundaries with how creative I can be with technology, and I’ll never run out of new concepts to learn.
So that’s what I love to do - to be involved with learning and teaching technology. That’s why I usually say opportunities to present online learning courses.
In April 2017, presented a course on Microsoft Virtual Academy called Introduction to Azure IoT.
The course served to introduce curious viewers to IoT in general as well as to the broad offerings of Azure in the area of IoT, and it also served to introduce viewers to the more in-depth course on the same subject available on the edX platform. Jump over to Developing IoT Solutions Using Azure IoT (DEV225) on edX now.
You can download this PowerPoint deck to get a deeper sense of what was covered as well as to get a reference to the various external links that I used.
Here are the topics…
Hope this helps you ramp up on IoT!
There are two types of gateways in the IoT (Internet of Things) world.
The first is a field gateway. It’s called such because it resides in the “field” - that is it’s on location and not in the cloud. It’s in the factory or on the robot for instance. Microsoft has an open source codebase for field gateways called the Azure IoT Gateway SDK you can start with.
The second is a cloud gateway, and obviously that one is in the cloud. Microsoft has a codebase for one common cloud gateway function - protocol adaptation available at Azure IoT Protocol Gateway.
Both of these entities exist as a point of communication through which you direct your IoT traffic messages for various reasons.
You’ll also hear the term edge to refer to devices and gateways in the field. The edge is the part of an IoT solution that’s touching the actual things. In the internet of cows, it’s the device hanging on the cow’s collar. In an airliner, it’s all the stuff on the plane itself (which I realize is a confusing scenario since technically those devices may also be in a cloud).
Some possible reasons gateways exist are…
you need to filter the data. It may be that qualifying data deserves the trip to the cloud, but the rest just needs to be archived to local mass storage or even completely ignored.
you need to aggregate the data. Your messages may be too granular, and what you really want to send to the cloud is a moving average, a batch of each 1000 messages, a batch of messages every hour, or something else.
you need to react to your data quickly. It doesn’t usually take that long to get to the cloud and back, but then again “long” is relative. If you’re trying to apply the brakes in a vehicle every millisecond counts.
you need to control costs. You can use filtering or aggregation to massage your messages before going to the cloud to reduce your costs, but there may be some other business logic you van apply to the same end.
you have some cross cutting concerns such as message logging, authorization, or security that a gateway can facilitate or enforce.
you need some additional capabilities. Devices that are not IP capable and able to encrypt messages are dependent on a field gateway to get any messages to the cloud. Devices that are able to speak securely to the cloud but are not for some reason capable to using one of the standard IoT protocols (HTTP, AMQP, or MQTT) require either a field gateway or a cloud gateway (such as Azure IoT Protocol Gateway).
What kind of hardware might you end up using for a gateway? Well, the possibilities are very broad. It could be anything from a Raspberry Pi to a very expensive, dedicated gateway system.
Also, Azure maintains a big catalog of certified hardware including gateways that might be the most helpful resource.
There’s certainly a lot more about gateways to know, but I’ll leave this here now in case it helps you out.