What to Consider When Choosing Common Coding Platforms for IoT

Right now, the Internet of Things (IoT) platform market is filled with over 100 contenders vying to become the next SAP. The platform business is very profitable and long-lived (platforms aren’t changed that often), so the winner stands to reap plenty of rewards for becoming “the” IoT platform. It’s a compelling opportunity for those looking to develop a platform, but not if you’re trying to decide on one for your IoT application. Which do you choose? Do you choose at all? Do you have time to wait?  Should you do it yourself? Do you have the resources? There are almost as many questions as there are potential IoT platforms. Here is some advice to help you through the process.

Common services of an IoT platform

A platform, in the most basic definition, provides a set of services that address common functions used by many specific applications. IoT applications usually consist of three layers, each needing to be addressed by the platform.

  • Edge nodes — Generally simple sensors aggregated together by the gateway. Sometimes these edge nodes are in harsh environments with erratic communication.
  • Gateways —Deployed in a location somewhere between the edge nodes and the cloud (for example, on the factory floor), gateways aggregate the data from the edge nodes and transmit the data to the cloud. Communication between the gateway and the cloud can be tenuous and sometimes requires the gateway to perform some local processing before sending the data to the cloud.
  • Cloud —Collects the information from the gateways. This is where the IoT applications reside and operate.  

For these reasons and others, enterprise platforms are not suited for developing IoT applications. Companies today either develop common services from scratch or buy an IoT platform from one of the many contenders. With no clear consensus of the common requirements, evaluating an IoT platform is overwhelming. Boiling the list of services of an IoT platform down to the least common denominator, this is the way to view the problem:

Configuration/Discovery

A platform should be able to discover what is plugged into your system. Discovery allows you to add these new elements automatically (such as adding an Apple printer in the iOS platform) or with minimum configuration effort. When you have edge nodes scattered far and wide, or if they are complex to configure, this certainly becomes a requirement of a platform.

Sending and receiving data

The data stream for the IoT environment flows from the edge nodes and connects to the gateway. The gateway has two interfaces—one from the edge node and one to the cloud. Typically the data goes in one direction, but that’s not always the case. Sometimes you need to send commands back out to the edge nodes as a result of analysis in the cloud.

Scalability of the interfaces between the gateways and the cloud must also be considered. You may find yourself in a situation where a system originally designed to have, let’s say, 5 things reporting to it now has 500, or maybe 5,000. Requirements for communicating between these elements have to be considered. Criticality of data, network availability, and network reliability become concerns for IoT systems. A platform to address these interfaces and related functions will certainly free up many development hours.

Security

The Internet of Things has created access to devices that have not previously been connected to the Internet. When there was no Internet connection, claiming a device was secure was easy, since there was little an external attacker could do to compromise it. But once you grant access to the device, even if it’s through a local network, it can be subject to remote attacks. All of the interfaces involved in an IoT system must be scrutinized for possible vulnerability issues. This is a critical service for an appropriate platform.

Embedded Systems IoT vs. Consumer IoT

In addition to the common services, when shopping for IoT platforms, consider the “things” you are connecting. If you are in the consumer market, the probability of the devices being replaced increases dramatically. Think of the frequency some personal devices are upgraded, either due to new technology, or simply a shorter product life expectancy. Longevity of the platform in this market a less critical concern.

Embedded systems, on the other hand, have a much longer life expectancy. Companies buying an HVAC system, for example, aren’t planning to replace it next year. Some of these systems may be intended to remain in use for decades. In these situations, when evaluating an IoT platform, the software you choose is going to need to be around for quite some time. Can you count on the promises of any one of the hundreds of contenders? For this reason alone, committing to an Industrial IoT platform is asking a lot from a company. What happens if the company you choose ends up not winning the platform game? On the other hand, you can’t wait forever. You have to do something. You can either develop your own platform and commit to supporting it, or you can try to pick the winner in your space—a dangerous gamble.

Things to know

Gambling doesn’t always have a bad outcome. Increasing your knowledge can improve your odds. For example, IoT platforms geared to operate in your industry can certainly improve the odds that the platform will address services common to your specific space.

Longevity issues can be addressed by asking the platform provider simple questions such as:

      • How will you handle support if we decide to change or upgrade our hardware?
      • Does your platform have a service to “containerize” apps in the event we need to change the platform?
      • How will you support any new builds we have in our roadmap?

No company plans on going out of business, but having a frank discussion as part of the evaluation can offer valuable insight the vendor’s business philosophies. Treat your platform vendor the same as you would any business arrangement. Their business practices, philosophies, and the direction of their company should all be considered before you make a decision.

In the end, you may decide to take the risk and swap out the platform if and when the time arrives. To help mitigate your risk, consider getting the source code or having it escrowed, so that you can protect your business from platform changes in the future. Escrowed source code is not available to the customer unless certain conditions arise. Obtaining or escrowing source code can help reduce the risk to early adopters of an IoT platform.

Evaluating whether you can build your entire application in-house or need to purchase a IoT platform is the same buy-vs-build decision that everyone in technology makes. You have to ask yourself several questions.

      • What specific problem are we addressing, or what capability are we missing?
      • Do we have the talent to build it in-house?
      • Is this the most efficient use of my team?
      • Can I buy exactly what I need?
      • What is the learning curve for implementation?

There are many considerations in deciding if you need, or are ready to commit to, an IoT platform. Knowledge is the key. Stay informed about the countless IoT platform offerings, and be both realistic and specific about your company’s needs and abilities.