This vendor-written tech primer has been edited by Network World 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?

Once you have decided how you will address these critical IoT communication issues, you must next investigate the server-side infrastructure to support your IoT application. This leads to a different set of issues, including:

• Scaling—Do you need to quickly scale up and down your communication capacity to support peak times or a rapidly growing business? Can you automate the scaling? Can you leverage third-party service providers to augment your internal infrastructure for rapid elasticity?

• Security and privacy—How do you build-in and maintain a secure infrastructure? What is your plan for maintaining and patching servers, storage, and routers? Is your infrastructure susceptible to hacking, phishing or social engineering? What about physical security? How do you handle regulatory requirements such as HIPPA and SOX? How do you handle law enforcement issues?

• Geophysical presence—Do you need a geophysical presence to support adequate network latencies or to fulfill regulatory compliance? Do your customers require non-US data storage?

• Uptime and SLAs—What are your applications’ uptime requirements? Do you have service guarantees (service level agreements or SLAs)? How will you meet your requirements? Do you have disaster recovery plans and sites? Do you have the ability to test your infrastructure for resiliency?

• Support—Does your infrastructure require 24x7x365 staffing and support?

Addressing all of these issues takes a highly specialized and technically proficient engineering team. You must also invest in the development and testing efforts. Most importantly, building your own robust, secure, reliable IoT communication stack takes a significant amount of time, which can impact your application time-to-market. Engineering talent, time and capital are all challenges for large organizations, and may put developing a custom solution out of reach for small teams and startups.

Buy or rent an IoT communication stack?

Instead of building your own custom stack, you can acquire and run your own. There are numerous open source and commercial communication solutions available that address many of the IoT M2M issues. However, open source software often lacks adequate documentation and support. And feature roadmaps, schedules and bug fixes are at the whim and mercy of the stack maintainers.

Commercial offerings may be a better option as they typically provide support and bug fixes for both client libraries and server side components.  However, teams tend to underestimate the time and costs associated with deploying and maintaining a 24/7 distributed infrastructure needed to support real-time applications.  

Instead of building your own, or acquiring the entire stack, you can “rent” the software stack and server side infrastructure. Software-as-a-service (SaaS) companies are now providing end-to-end IoT communications environments, combining software for virtually any device with a complete server side communication infrastructure. These service providers solve most, if not all, of the communication and server issues.

SaaS providers have already invested the time, money, and resources to become the authorities in IoT communications. They have dedicated experts in security, networking, communications and operations. They have built scalable, secure, reliable and resilient server side infrastructures to support large and rapidly expanding IoT applications.

With multiple providers, you have a choice of features, functionality and services. Some vendors choose to be generalists, providing a comprehensive suite of services to meet most basic IoT requirements. Other providers focus on becoming specialists, providing unique features such as minimum worldwide latency, global redundancy and uptime guarantees.

SaaS providers offer multiple pricing models, from per-device or per-node charges to charges based on transactions or data volume. Other factors that affect pricing include SLAs, QoS, geophysical presence and per-feature charges. This gives you flexibility and the ability to control your costs based on your specific application. It also allows you to start small and grow as your application grows, limiting your capital investment.

SaaS solutions are designed to be quick and easy to integrate into your application. In fact, some solutions require only a few lines of code. This allows you to focus on your application, ignoring all of the complexities of IoT communications. The speed and simplicity of SaaS solutions lend themselves to the fail early, fail fast and fail often development model, ensuring that you rapidly innovate towards the most valuable solutions and once you launch, they can scale with your business.

In conclusion, as with most other business decisions, the build versus buy decision boils down to time versus money, CapEx versus OpEx, and Total Cost of Ownership. Building your own IoT communication stack, with or without commercial or open source software, ensures that you have every feature you need. However, it takes a significant investment of time, capital and resources and requires highly specialized technical expertise. 

You should only build your own solution if you can a) create a competitive advantage with your custom software, b) build a big enough business to spread the cost of your proprietary system over a large number of clients, minimizing the per-client cost of the effort c) afford the long time to market and d) have the in-house expertise needed to build and maintain a complex distributed computing environment. 

Given the IoT is still in the early stages the more practical and pragmatic strategy is to use a SaaS provider, enabling you to develop robust, secure and reliable IoT applications while drastically shrinking your capital investment, development.