An Internet of Things Demo Jam: Architecting the Scene

I believe that the Internet of Things (IoT) is a popular topic, in part, because its science-fiction becoming science-fact.  IoT promises all of the conveniences of “The Jetsons” without having to push buttons, while threatening to produce the surveillance states of “1984” or “Minority Report”.  Unfortunately, it most likely will give rise to the annoying doorways from Douglas Adam’s “Hitchhiker’s Guide to the Galaxy”, that have micro-transactional charges per use and in-app purchases that “allow” the door to open after 5pm.  For our IoT demo, I took the more lighthearted approach of The Jetsons and Mr. Adams, but the proposed technologies and architectures are very professional and scientific, and deserve a more serious discussion.

 

Aside from security concerns, one of the biggest issues with the Internet of Things is the sheer volume of data that can be generated from an ever increasing number of smart-objects demanding an internet connection and inter-connectivity.  But, how often does your toaster need to report on bread consumption to the refrigerator, Alexa’s shopping cart, your electric knife, the grocery store, the toaster’s manufacturer or your bedroom shower, just because it happens to be in wi-fi range?

 

A three tiered architecture in your home, with an intelligent gateway helps alleviate these traffic concerns, eliminates the waste of redundant data storage, and can provide some additional privacy and security safeguards.  In this architectural pattern, the smart gateway sits between the edge devices or sensors (toaster, knife, fridge) and the data centers (Alexa, grocery store, toaster company) to proxy and filter the communications.  A toaster should probably only send bread consumption data after each use, but what if it sends out data every hour or every minute.  If the important information hasn’t changed, how vital is it to send that data to the refrigerator or the grocery store?  A smart gateway decides what is important and determines when communication should occur.  As an aside, this is the most consideration I ever have, and ever want, to give to toaster communication patterns, and I would hope and expect that a home smart gateway product would handle these concerns for me in the future.

 

Another fundamental aspect to the demo’s architecture is the adoption of containers and microservices at both the data center and smart gateway.  Our demo used a Raspberry Pi 3B for the smart gateway, but just because its a $35 computer, doesn’t mean that you shouldn’t use the most modern design patterns and Red Hat technologies.  Even on a Raspberry Pi, containers can be implemented to use resources more efficiently.  The data center was built using Red Hat’s Container Development Kit (CDK) which is a single-node OpenShift cluster, built on Linux containers, Docker and Kubernetes, that runs locally on my laptop.  In a more production like environment, I would suggest leveraging a full OpenShift Container Platform (OCP) installation running on-premise, in a public or private cloud, or even a hybrid cloud environment.  OpenShift is an innovative, enterprise-grade, container platform which accelerates application development by implementing self-service provisioning and enabling DevOps through department-wide collaboration.

 

If you have questions about any of these products or about the IoT demo architecture, please reach out to me directly at redhat-solutions@www.dlt.com.  On my next post in this series, I will take a closer look at the technologies behind my individual microservices.