3 critical components of connected object infrastructure

Here are a few areas to consider carefully for guaranteeing the success of an Internet of things project

Credit: CC0 Public Domain

The Internet of things is a hot topic, and it will not be long before many businesses embark on some kind of connected objects project.

By definition, a connected object is part of a broader platform -- connected to a backend, often in the cloud, the connected object receives instructions or parameters from the backend, and/or sends to this backend data points collected by its sensors. For example, an intelligent thermostat is instructed by its backend to maintain a defined temperature and sends back temperature and presence measurements; an intelligent energy meter sends readings to its backend and can adjust maximum permitted wattage upon receipt of instructions.

The ability of connected objects to function properly therefore depends on 3 critical components in the infrastructure that we examine here.

APIs that communicate with the backend

Communication between remote objects and their backend, regardless of the transport protocol (Bluetooth via a mobile gateway, WiFi, cellular, etc.) is done via calls to RESTful APIs. Based on a standardized architectural style and leveraging the capabilities of the HTTP protocol, Web APIs (as they are commonly called) are the most flexible and versatile option to connect objects.

There are a few issues to consider though, to ensure that the APIs will smoothly support the connected objects:

  • Scalability: you probably want to scale the number of connected objects you’ll deploy, so you need to ensure that the backend infrastructure will support spikes of calls. And since you don’t have control over when exactly each object will connect, you should plan for an uneven time distribution and peaks of traffic.
  • Error management: if the backend if unavailable or overloaded, send back the proper status to the calling object so that it knows to retry in a timely fashion.
  • Access concurrency: make sure that your API calls don’t lock resources needed by other objects.
  • Push vs. pull: if the object needs to poll the backend frequently to stay up-to-date while actual updates are infrequent, consider a push mechanism to avoid costly repeated requests.

Data backend

Behind the API, you will typically deploy a database of some sort. Beyond the need for this database to scale to support the number of concurrent requests, the following aspects must be considered:

  • Transactional consistency: it can be required in cases, but not always. For example, if your use case involves the collection of sensor metrics, you may decide to relax consistency in order to improve the speed of data writes. NoSQL databases offer good alternatives to ACID-compliant databases.
  • Data volumes: the added value of most Internet of Things use cases is the ability for the backend to store and correlate enormous amounts of data, and provide advanced analytics or patterns. Don’t underestimate the growth of data over time. For example, a network of smart meters sending measurements every 15 minutes will collect 10,000 more data points than the quarterly readings made previously.


Not every Internet of things application needs to comply with stringent confidentiality or medical/industrial life-or-death requirements, but still a security breach can be at the very least highly embarrassing, or even result in financial losses if data used for billing is compromised. Look specifically at these risk areas:

  • Secure the exchanges with the backend. REST APIs support HTTPS encryption, so use it.
  • Implement advanced authentication protocols. Don’t overburden the system with overly complicated security, but still, implement what’s necessary to avoid hacks.
  • Properly define and automate processes to handle permissions, user/device provisioning, and more importantly user/device deprovisioning. This sounds obvious but when objects are counted in thousands or millions, you need to have the proper systems in place.
  • Monitor and limit traffic per connected object. Spikes in traffic can be legitimate, but can also be a symptom of a DoS attack. At the very least you want to be alerted of suspect/marginal behavior.

This article is published as part of the IDG Contributor Network. Want to Join?