With all the buzz surrounding IoT, it’s fair to assert we are in the midst of another shift in computing. Enabled by cheaper hardware and elastic cloud based services, we have built massive scale systems spanning from the smallest micro controllers to “unlimited” storage and compute power in the back end.

At the same time we have seen the explosion in APIs. They are powering the app economy as the integration layer between apps. For example, if you’re building a mobile app, you need to get the data from the backend to the app in a secure fashion. That app likely requires integration into a number of cloud services, spanning from social to enterprise business systems. That integration is achieved using an API management or home grown solution or maybe just a raw “private” API.

There are several ways to look at IoT and its huge spectrum of uses. In some, humans are interacting with machines; in others its machines to machines, or mixes of these. You could also divide use cases between industrial and consumer IoT where the former tackles industrial automation and the latter often relates to consumer electronics and gadget-of-the-day mania. Regardless, the span and diversity of systems that can be called IoT is significant and complex, making management and security of those systems a challenge.

Observations of IoT Systems

If we assume it will be hard to find a single platform to handle IoT management and security, let’s start with some observations from an API management perspective of some areas we typically see in an IoT and that may be involved in a system implementation. This means at the API layer (as in Layer 7) we don’t focus on wireless connectivity technologies underpinning the various systems such as Z10, Zigbee and all its variants of mesh networks. These are important, but less so in an API centric world:

1. No standard for client side software or hardware. Unlike the PC industry, the mobile industry never provided a standard runtime for apps. For smart THINGS this is even more true where the definition of a THING spans from the smallest of micro controllers to full-fledged operating systems running on multicore architectures. But, usually, a THING is designed for a single task and that alone. When this gets connected in a larger system of connected THINGS interoperability becomes an issue. And you never know what kind of security is available on a THING and when you, as a developer, try to connect it to your enterprise backend, you must add layers of complexity per component.
2. Identify everything. In the common enterprise scenario any user that connects and consumes an API has been provisioned with an enterprise identity. In some cases, typically if this is a customer or consumer, the identity provider may be external such as a social login provider. But generally speaking it’s a single domain controlled by the enterprise. Moving along to connected THINGs you are adding orders of magnitudes of identities. Essentially, and this has been said by others, “Everything with an Identity will have an API and everything with an API will have an Identity.”

   The implication of this is that the enterprise will have to deal with a diverse set of identities across users, apps, and things when crafting and enforcing the security and access polices. Across the IoT use cases there are many forms of identities; every car, every thermostat in a house, every phone, every app will have multiple identities. These may be explicit, such as a device ID, or implicit, such as an identity context derived from attributes like IP address, geographic location, API key, time of day, etc.

   All of these identities will need to be managed together with APIs.

3. New threat space. Many of the same security considerations that you have when writing mobile apps will be valid in IoT scenario, only an order of magnitude greater. In a mobile app scenario you take for granted that a user is at least trying to look after the device. On a lucky day maybe they use a passcode as well. And you may be able to prevent malicious attacks by using Samsung KNOX?type of technologies. But what about that sensor or thing that sits in the public space? Someone with malicious intent may have easy physical access, and the thing itself is likely to be constrained and lack cryptographic capabilities, so the threat space is just that much larger.
4. Transport challenges. In an IoT system there are many roles and entities that are cooperating to achieve a goal. These tend to span from cloud based API servers, to clients (see 1 above), mobile apps and to third party systems which all need to provide updates and notify other components about state changes. The nature of these systems lends itself to a pub-sub paradigm where you will get loose coupling between the components. How you set up the transport and trust between the components are hard problems not yet solved at industry level.
5. Big Data challenge. It’s has been claimed ‘data is king,’ but data on its own has little value. To get the most value out of an IoT system, a big data platform is required to analyze and compute insights that can be used by other apps. To do this, you need to make sure you externalize the data and insights to the desired audience, through APIs.
6. Visualization of IoT insights. Once you have computed your insights there must be a method for visualizing in a meaningful manner. You may need to combine and relate your IoT events in a geographical context on a map or you may require a 3D space visualization like in a smart city monitoring system. An example of an IoT visual rendering capability can be found in the CyberVille platform.
7. User control. With more THINGs being connected to the Internet, providing data about users and resources, there is an increased need for users to stay in control of what they share and with whom. For example, you will be able to use social identities to share access to your car, house or even health data. Likewise, if you share something, you may equally want to revoke access at some point. Essentially, IoT can empower users not only by providing better information but also with frameworks that enable user controlled authorizations. As an example, the Blackphone?takes a fresh look at privacy, with a main focus on protecting access to data.

The IoT Platform That Doesn’t Exist

IoT is the coming together of connected devices and cloud computing in a symbiotic relationship. From the device perspective, the cloud offers infinite resources for computing, networking and storage. From the cloud perspective, a mobile device offers proximity to users as it is at arm’s length distance nearly 24/7. When you add connected THINGs to the mix, the cloud could possibly start sensing and interact with the environment. By connecting the two sides you enable an unparalleled computing engine that has the potential to be reactive and truly omnipresent.

It’s clear that defining a single platform that can cover such a vast number of use cases will be hard. Instead, if we try to identify the system components likely to be involved, we get a better picture of what is required.

Across many IoT systems you will find some common entities:

The Thing

In diagram 1, there is a notion of sensors/actuators, in this case a door lock. This is usually the “thing” part in IoT. A thing may have various degrees of capabilities, from both a hardware and software perspective. It could be a general processing unit but more likely a microcontroller. The point is that it is a highly fragmented entity and nobody controls this space to even get a de facto standard established. Sometimes the sensor or thing is able to communicate directly with the cloud node through Internet protocols while other times it will go through a mesh network and a local gateway. In some cases these THINGS can interact with other things through proximity technologies like Zigbee, BLE or NFC. There is a myriad of connectivity options that are unlikely to converge anytime soon. Different use cases and contexts will drive this.

The Phone

The other entity that we increasingly see in use cases is the smart phone. There is lot of investment from Samsung and Apple in this area. This is the next battleground between iOS and Android ecosystems. What is the objective for the smartphone in IoT? The smartphone has become an extension of the user connected to work and personal activities. With IoT, the mobile phone takes an even more central place in people’s lives, or everyday tasks, such as unlocking cars and houses, controlling TVs, payment and more. As the mobile phone interacts with other objects that may or may not be Internet enabled, the use cases become more intricate as do the security and privacy implications.

The API Server

In the backend of an IoT system we find the API server and its data store. This is usually deployed on-premise, in the cloud or both. One of the key capabilities that enables the whole IoT segment is the elastic compute, storage and network capability provided by cloud and big data technologies. Without this we have a system of billions of sensors that nobody can use. Someone needs to compute insights that can then can be used by applications. Correlation services, analytics and intelligence about devices, users, apps and their data will be new capabilities that power the next generation of apps.

The Third Party App Server

The third party app server is where much of the value in an IoT system will be unlocked. The system above is all about sensing environment, generating data and events that then are being transported back into massive storage and processed. The next step in the value chain is to make sure that the insights are being used in net new applications that can benefit enterprises, users and society, be it through home automation, remote plant control, or traffic management. As the Samsung CEO said in his CES keynote, “There must be an ecosystem in place to unlock value of IoT.”

Diagram 1: IoT

The Missing Piece

In order to manage the interactions in an IoT system, an API management function seems like a good fit. The inbound traffic needs to be scrubbed, devices and users authenticated, and authorizations managed. On the outbound side the usual API management principles must be adhered to: an API portal for managing APIs and Developers. The latter needs to discover what APIs are available for their apps – be it virtual device APIs to interact with devices or other insights derived from data analysis.

In addition, the API management function must be enhanced to provide support for event based computing. There may be apps that require near real time delivery of data when specific conditions are met. To serve the vast diversity in use cases, an API management system must be able to handle standard HTTP API calls just as easily as a subscription based delivery.

An obvious use case in an IoT context is environment monitoring. In some cases, this data can be deciding system behavior in the client, in a system running near the sensor. In other cases, this data need to traverse the internet to a cloud or on-premise system. In general, there is a flow of data from the sensor towards the backend – the data plane. The functions associated are filtering, rate limiting and data scrubbing. The next set of issues that system developers are facing is how to assure that the data is real, relevant and authentic. How is the communication set up? This leads to the control plane?concept where we need to issue commands that can set up, monitor and manage a system. It’s clear that there would be fairly different set of access polices related to such capabilities.

In the end, the value of an IoT system will need to be surfaced to app developers in a meaningful way and the best tool for that would be APIs accompanied with SDKs supporting cross cutting concerns.

APIs are successfully fueling the app economy and all indicators show they will play a critical role in app economy 2.0 where more connected devices and things drive business operations.

?

About the Author

Leif Bildoy?is a Product Manager at CA Technologies where he plays a central role in defining the strategy and roadmap for the company’s API Management mobile products. Prior to joining CA (through the Layer 7 acquisition), Leif worked in product management and development in organizations including Alcatel Telecom, Nokia Research Center, SurfKitchen, MontaVista Software, and Research In Motion (Blackberry). He has an MSc in Advanced Computing from the University of Bristol, UK.

?

More articles in this series:

• The New Frontier of ‘Software-Defined Everything’
• Love, Marriage and Open APIs
• Event Horizon – The Future of APIs in the Internet of Things
• Surveying the Web API Security Landscape
• The Vision of Kay and Fielding: Growable Systems that Last for Decades
• Three Letters That Are Key to Driving Digital Transformation: A-P-I