This vendor-written tech primer has been edited by Executive Networks Media to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
The Internet of Things (IoT) is shepherding in the next communication revolution – machines communicating with other machines – at a scale and volume unfathomable until only very recently. The Internet comprises some 1 billion sites and around 5 billion devices. Predictions of growth for the next five years vary from the mundane 25 billion to the wild extremes of 50 or even 100 billion Internet connected devices.
To make IoT successful, developers will need to connect these billions of devices in a meaningful way, delivering truly distributed machine-to-machine (M2M) computing and device control. However, the IoT M2M challenge is also about ensuring security, reliability, privacy and realtime communications on a plethora of devices hobbled by small, low power CPUs and limited memory. And the question is, do you build or buy the IoT communications stack?
One of the biggest benefits gained by building your stack is you can design software that does exactly what you want, meeting every single need of your application, but that comes with both short- and long-term costs and a lot of unknowns. As you investigate building your own IoT communication stack you should not only consider the obvious build and maintenance costs and time-to-market factors, but also the following:
- Security—Security is emerging as the most important aspect of any digital system, from cars to homes, to wristwatches and phones. Security is even more important for broader IoT, as more and more devices interact with the physical world. Secure communications, security of the device and security of the application servers are just a few of the many aspects of IoT security. Once hackers break in, they can wreak havoc on your devices, your users and your business. Do you have up-to-date encryption and security expertise in your development team? Do you have the ability to continuously update your communication stack to keep up with the latest vulnerabilities? Will you be able to bake in security throughout your application, servers and devices?
- Push vs. pull notifications—Implementing pull can be easy, but can have major impacts on device battery life and the amount of data transmitted using potentially expensive networks. For example, when implementing a pull architecture, the polling must be set frequently enough so your devices or servers get the data in a timely fashion. In order to do so, you must have servers available to handle a lot of empty requests, which can be costly. Implementing push is much more difficult, especially if the application must support a wide variety of devices, operating systems and networks. In order to support live push notifications you must establish a secure open socket connection, which can open up security risks if not done correctly. However, the advantages lie in getting data to the right devices at the right time instantly anywhere in the world. Which do you need for your application?
- Access management—How do you ensure your communication goes to the correct devices and users? For that matter, how do you identify your different users and devices? How do you enforce permissions? Do you need two factor authentication?
- Mobility—Many IoT devices will be mobile, accessing the internet over Wi-Fi or cellular data networks. This means constantly changing device addresses, intermittent connectivity, long periods of communication failures and noisy, error-filled messages. Do you have the ability to limit data transfer on expensive or slow networks? Do you need message-level checksums? How do you handle missed messages and redelivery? Can you handle rapidly changing addresses? How well do you understand how mobility affects the intricacies of networking protocols?
- Network Connectivity—Can your application withstand network connectivity issues including latency, jitter, slow links and intermittency? Do you need guaranteed quality of service (QoS)?
- Presence detection—Can you detect when a user or device goes online or offline? If you lose connection with a device, does your application care if there was a network failure, a device failure or the user decided to exit the application?
- Message storage and playback—Do you have the ability to store messages destined for an unreachable device and the ability to play back those messages when the device reconnects? Does your device have the ability to store and playback messages destined for the server or other devices during connectivity outages?
- Realtime—What does realtime mean for your IoT application? Do messages need to arrive within a certain time frame? Do you need to acknowledge messages? What happens if messages arrive out of order?
- Analytics—How do you measure your communications infrastructure to ensure reliability, security and efficiency?
Sign up for Computerworld eNewsletters.