Industrial IoT: Demand Study
Hello colleagues.
Today we want to discuss with you such a non-trivial topic as IoT architecture for large enterprises. The popularization of IoT in Russian is well under way, but the first serious books about the architecture of such solutions in the scale of (large) enterprises are already in English. We are pretty interested in the following book by Perry Lea:
We ask you to actively speak about the relevance of this book. If someone wants to share the real experience of the implementation of industrial IoT in Russia and / or review the translation of the book - also write.
')
Under the cut, we offer the translation of the Red Hat publication, which addresses the issues of competent and secure API design for IoT systems.
The essence of IoT is in data management. The Internet of things receives data from devices, sends commands to devices, integrates IoT data with other information, on the basis of which it draws conclusions. Data sources are, in particular, devices, corporate systems, systems of suppliers and partners, as well as information from providers and customers. It is impossible to integrate all these systems using the “point-to-point” principle, therefore the main communication mechanism between these separate systems will be the API. A pure architectural approach that would be useful in this case is flexible integration . The central role in it is played by the API, ensuring the secure shared use of data between internal and external systems. By opening access to the API, the company can provide unified interfaces for exchanging data and transactions to freelance and full-time developers, partners, and customers. This optimizes data access and remote resource management. By providing well-defined APIs, developers can programmatically use data: for example, an application developer can access data from IoT devices without knowing what hardware interfaces these systems are based on. Considering how important APIs are when working with IoT, an organization simply has to effectively manage these APIs. Yes, APIs are considered a fundamental factor in the implementation of IoT, however, they need to be reasonably managed; without such control, uncontrolled reproduction of an API can easily lead to a catastrophe.
API management ensures their uniformity in various applications, business models, as well as among different stakeholders. In addition, when monitoring the API, you can identify anomalies in various practical situations and take corrective measures in real time.
API Management Components
The most prominent component involved in managing an API is the gateway listening to traffic from the API. This should be a highly scalable reverse bandwidth proxy server, for example, Nginx. The gateway can be located in the enterprise or in the cloud, but ideally in the same place as the machine interface.
The less noticeable but equally important components of an API management solution are security aspects, usage policies that govern issues such as frequency limiting, analytics, reporting, the developer portal, and monetization.
To support systems with differing capabilities, you need to support a variety of security enhancement, access control, and control mechanisms, such as an API key, tokens, OAuth, or external identity management. For example, the OpenID Connect mechanism, which can store a reference identifier and act as a broker, serving various accounts in social networks or in corporate applications (say, Google, LDAP, Active Directory and Kerberos) will do.
Using an API without authentication, we run the risk of losing data or running into security problems — like in a recent episode when the Nissan Leaf API was hacked. In the Nissan Leaf car application, only the vehicle identification number (VIN) was used to call the various services to which the car is connected. Imagine the risks if you apply a similar method — that is, access to the machine interface via an API that does not provide authentication — will be applied in the vehicle control module or in another critical IoT infrastructure node. Consequently, access to all Internet of Things devices, even those located behind a corporate firewall, should be governed by clearly defined security policies.
A company must be able to set different levels of access and frequency limits for different categories of users, device types, and data types. This provides an additional level of security in the IoT infrastructure. For example, if a hacked device begins to send abnormal amounts of data (as in the case of a DDoS attack), then such an infected device can be quickly detected, isolated and removed from the network before it can damage the entire system. Given that many IoT devices do not have any security mechanisms, and there are no regular updates, it is reasonable not to allow any direct access to these devices, except through the API gateway that serves as a firewall.
With analytics and reporting, you can monitor and observe the use of the API and take action when the user reaches some critical values. So you can determine which APIs and terminals are most popular, and which ones are not used. Monitoring the use of the API also contributes to monetization: it is possible to charge user access to the API or the actual consumption of this API.
The developer portal allows you to register for an API, extract API credentials, including keys, find the documentation for this API and track its performance. Data on how developers apply to devices and systems can be dynamically updated during the project life cycle — for example, at the design stage, provide unrestricted access to all IoT devices, and after devices are deployed in production, restrict such access.
Important notes
To avoid a single point of failure, the API management solution must be distributed, well scaled and deployed in a variety of environments (both in the enterprise and in the cloud). In this solution, control nodes and policy management should be separated. To achieve the desired flexibility, the solution must also be automated; in this case, it is convenient to use popular free tools, for example, Ansible, Puppet and Chef.
When working with IoT data with a limited duration, the delays should be minimal; therefore, it is necessary to organize local caching of keys / tokens on the API gateway so that the call can pass directly through the API. The API Policy Manager can be invoked asynchronously, as required by the Service Level Agreement (SLA).
This approach allows you to maintain high performance and minimal latency, which is very important for IoT solutions.
As for equipping the gateway with additional functions, for example, protocol adapters, it is recommended not to mix the implementations of these features (integration, mediation or data conversion) and place them at the integration level located behind the API gateway. At this level, free projects such as Apache Camel or Red Hat JBoss Fuse (in production) should be used.
An example of managing APIs in a business model using IoT is the Kapua project, which is handled by the Eclipse working group on IoT implementation. Kapua demonstrates how open-source innovations provide access to managing IoT gateways and boundary devices. It provides not only a basic framework for integration, but also a set of IoT services, including a device registry, device management services, messaging services, data management, and application activation. To integrate with existing applications, Eclipse Kapua provides a REST API that provides all platform functionality.
This REST API also offers access to the MQTT broker, which provides routing commands from applications to devices and does not require a specific connection to the message broker. It uses technologies such as REST / Comet / WebSockets, which allow real-time publishing of data published by devices on web pages and mobile information panels.
Through management at the API level, Eclipse Kapua services can be publicly shared through an API gateway. Using the method of flexible integration, we can offer the entire solution as a set of container microservices. Working with a container orchestration platform, for example, with Kubernetes, we gain further by acquiring the ability to automatically scale resources as our IoT configuration grows.
Conclusion
The API is one of the main mechanisms that ensure the operation of a large digital enterprise and one of the key aspects in the concept of flexible integration. APIs have been popularized thanks to the widespread use of services such as Google maps, and now they form the foundation of user interactions in the digital world. Fast, adaptive IoT solutions especially benefit from flexible integration using modern platforms, processes and technologies. APIs become the main communication mechanism between disparate IoT systems and are convenient for both regular and freelance developers, as well as partners and clients. Given the importance of APIs for IoT, an organization simply has to manage these APIs effectively.
Today we want to discuss with you such a non-trivial topic as IoT architecture for large enterprises. The popularization of IoT in Russian is well under way, but the first serious books about the architecture of such solutions in the scale of (large) enterprises are already in English. We are pretty interested in the following book by Perry Lea:
We ask you to actively speak about the relevance of this book. If someone wants to share the real experience of the implementation of industrial IoT in Russia and / or review the translation of the book - also write.
')
Under the cut, we offer the translation of the Red Hat publication, which addresses the issues of competent and secure API design for IoT systems.
The essence of IoT is in data management. The Internet of things receives data from devices, sends commands to devices, integrates IoT data with other information, on the basis of which it draws conclusions. Data sources are, in particular, devices, corporate systems, systems of suppliers and partners, as well as information from providers and customers. It is impossible to integrate all these systems using the “point-to-point” principle, therefore the main communication mechanism between these separate systems will be the API. A pure architectural approach that would be useful in this case is flexible integration . The central role in it is played by the API, ensuring the secure shared use of data between internal and external systems. By opening access to the API, the company can provide unified interfaces for exchanging data and transactions to freelance and full-time developers, partners, and customers. This optimizes data access and remote resource management. By providing well-defined APIs, developers can programmatically use data: for example, an application developer can access data from IoT devices without knowing what hardware interfaces these systems are based on. Considering how important APIs are when working with IoT, an organization simply has to effectively manage these APIs. Yes, APIs are considered a fundamental factor in the implementation of IoT, however, they need to be reasonably managed; without such control, uncontrolled reproduction of an API can easily lead to a catastrophe.
API management ensures their uniformity in various applications, business models, as well as among different stakeholders. In addition, when monitoring the API, you can identify anomalies in various practical situations and take corrective measures in real time.
API Management Components
The most prominent component involved in managing an API is the gateway listening to traffic from the API. This should be a highly scalable reverse bandwidth proxy server, for example, Nginx. The gateway can be located in the enterprise or in the cloud, but ideally in the same place as the machine interface.
The less noticeable but equally important components of an API management solution are security aspects, usage policies that govern issues such as frequency limiting, analytics, reporting, the developer portal, and monetization.
To support systems with differing capabilities, you need to support a variety of security enhancement, access control, and control mechanisms, such as an API key, tokens, OAuth, or external identity management. For example, the OpenID Connect mechanism, which can store a reference identifier and act as a broker, serving various accounts in social networks or in corporate applications (say, Google, LDAP, Active Directory and Kerberos) will do.
Using an API without authentication, we run the risk of losing data or running into security problems — like in a recent episode when the Nissan Leaf API was hacked. In the Nissan Leaf car application, only the vehicle identification number (VIN) was used to call the various services to which the car is connected. Imagine the risks if you apply a similar method — that is, access to the machine interface via an API that does not provide authentication — will be applied in the vehicle control module or in another critical IoT infrastructure node. Consequently, access to all Internet of Things devices, even those located behind a corporate firewall, should be governed by clearly defined security policies.
A company must be able to set different levels of access and frequency limits for different categories of users, device types, and data types. This provides an additional level of security in the IoT infrastructure. For example, if a hacked device begins to send abnormal amounts of data (as in the case of a DDoS attack), then such an infected device can be quickly detected, isolated and removed from the network before it can damage the entire system. Given that many IoT devices do not have any security mechanisms, and there are no regular updates, it is reasonable not to allow any direct access to these devices, except through the API gateway that serves as a firewall.
With analytics and reporting, you can monitor and observe the use of the API and take action when the user reaches some critical values. So you can determine which APIs and terminals are most popular, and which ones are not used. Monitoring the use of the API also contributes to monetization: it is possible to charge user access to the API or the actual consumption of this API.
The developer portal allows you to register for an API, extract API credentials, including keys, find the documentation for this API and track its performance. Data on how developers apply to devices and systems can be dynamically updated during the project life cycle — for example, at the design stage, provide unrestricted access to all IoT devices, and after devices are deployed in production, restrict such access.
Important notes
To avoid a single point of failure, the API management solution must be distributed, well scaled and deployed in a variety of environments (both in the enterprise and in the cloud). In this solution, control nodes and policy management should be separated. To achieve the desired flexibility, the solution must also be automated; in this case, it is convenient to use popular free tools, for example, Ansible, Puppet and Chef.
When working with IoT data with a limited duration, the delays should be minimal; therefore, it is necessary to organize local caching of keys / tokens on the API gateway so that the call can pass directly through the API. The API Policy Manager can be invoked asynchronously, as required by the Service Level Agreement (SLA).
This approach allows you to maintain high performance and minimal latency, which is very important for IoT solutions.
As for equipping the gateway with additional functions, for example, protocol adapters, it is recommended not to mix the implementations of these features (integration, mediation or data conversion) and place them at the integration level located behind the API gateway. At this level, free projects such as Apache Camel or Red Hat JBoss Fuse (in production) should be used.
An example of managing APIs in a business model using IoT is the Kapua project, which is handled by the Eclipse working group on IoT implementation. Kapua demonstrates how open-source innovations provide access to managing IoT gateways and boundary devices. It provides not only a basic framework for integration, but also a set of IoT services, including a device registry, device management services, messaging services, data management, and application activation. To integrate with existing applications, Eclipse Kapua provides a REST API that provides all platform functionality.
This REST API also offers access to the MQTT broker, which provides routing commands from applications to devices and does not require a specific connection to the message broker. It uses technologies such as REST / Comet / WebSockets, which allow real-time publishing of data published by devices on web pages and mobile information panels.
Through management at the API level, Eclipse Kapua services can be publicly shared through an API gateway. Using the method of flexible integration, we can offer the entire solution as a set of container microservices. Working with a container orchestration platform, for example, with Kubernetes, we gain further by acquiring the ability to automatically scale resources as our IoT configuration grows.
Conclusion
The API is one of the main mechanisms that ensure the operation of a large digital enterprise and one of the key aspects in the concept of flexible integration. APIs have been popularized thanks to the widespread use of services such as Google maps, and now they form the foundation of user interactions in the digital world. Fast, adaptive IoT solutions especially benefit from flexible integration using modern platforms, processes and technologies. APIs become the main communication mechanism between disparate IoT systems and are convenient for both regular and freelance developers, as well as partners and clients. Given the importance of APIs for IoT, an organization simply has to manage these APIs effectively.
Source: https://habr.com/ru/post/358368/
All Articles