The number of devices connected to the Internet of Things (IoT) surpassed the number of smartphones and personal computers some time ago, and will overtake the number of people on the planet this year. Gartner estimates that over 20 billion devices will be connected to IoT by 2020, growing at about 30 percent annually.
Most IoT projects involve only a few hundred or thousand connected devices, but even a seemingly simple application can require hundreds of thousands of connections between devices and generate millions of information updates a second depending on the frequency of updates from those devices.
An IoT architecture with many devices, intermediary nodes (where aggregation and processing may occur) and back-end systems like applications and analytics engines was once an extreme example of distributed computing, but is the new norm.
With so many nodes as part of a single application, you can be sure that something will always be wrong somewhere – devices will need repair, the aggregating nodes will break or reach capacity, or some datacenter asset will be offline. At any given time, 99% plus of the entire system will behave as expected, but the problem that needs attention will always be different and fluid. And it’s critical that your IoT application run seamlessly whether all the components of the system are working perfectly or not.
The well-accepted way to deal with this challenge is to decouple the nodes and design all communication and data exchanges to be asynchronous. When everything is working correctly, data flows as anticipated and when something goes wrong, most data still flows as anticipated. In contrast, if an application tries to do this by connecting applications with point-to-point links, a single node’s problem often has a cascading effect that can shut the whole application down. The only alternative a developer has with this approach is to write reams of code that anticipate and work around every possible failure scenario. It gets unwieldy very quickly as illustrated here.
That’s why software architects and developers have turned to messaging to solve distributed computing problems for decades. Decoupling is a core tenet of computer science for distributed architectures. By decoupling endpoints, a message bus makes data exchange fully asynchronous, and can automatically handle caching, buffering and routing challenges when nodes experience failures or slowdowns. That’s why a well-designed message bus can automatically resolve most of the problems that would cause large-scale outages otherwise.
There are many more details related to IoT and messaging like message exchange patterns, protocols and APIs like MQTT, REST, JMS, AMQP and more. Check out my blog post “Understanding IoT Protocols – Matching your Requirements to the Right Option” to learn more which might be right for your applications.