In Internet of Things (IoT) systems, data frequently needs to be sent from a set of sensors to a database in a remote public cloud. The time it takes for the data to be transferred from the sensor or device to the cloud—that is, the latency—is often too long to meet the latency requirements of the IoT system. Thus, in some cases, the public cloud is avoided, and IoT systems can’t take advantage of the cost and resource efficiencies of cloud-based computing.
We need to do something different—and we can start by building IoT applications at the cloud’s edge. This means we avoid sending all data from sensors and devices back to the cloud, and instead build data and applications on the edge of the network, which can handle most of the data gathering and processing.
The idea of edge computing isn’t new, of course—we’ve been doing it for years to solve these same issues as they arise in other kinds of computing. For example, a cloudlet is an architectural element that arises from the convergence of mobile computing and cloud computing. It can be viewed as a “datacenter in a box,” with the goal of bringing the cloud closer. Another example is fog computing, which extends the cloud to be closer to devices that produce and act on IoT data.
However, many IoT applications need to react almost instantly to the data generated by a sensor or device, such as stopping a train if sensors detect problems with the track switch a few miles ahead, or shutting down an industrial machine that is about to overheat and have a catastrophic failure. There are hundreds of use cases where reaction time is key in an IoT system, which is why latency is such an important concept. To effectively manage data latency, I provide a physical reference architecture for an edged based responsive data architecture (RDA), a framework based on patterns seen in real IoT projects that leverage the cloud. Think of an RDA as a physical framework including major components—such as services and databases—that are represented in a configuration that can be replicated with new system instances. In other words, it is a starting point or checklist to create your own high-performing IoT system that also leverages a public cloud.
A Physical Architecture for Edge Processing
It has been a common problem for years: if a device generates large amounts data that needs to be processed instantly, then moving that data to a centralized database each time introduces latency. The IoT has similar issues of processing performance versus latency.
Consider, for example, a machine that analyzes the quality of an auto part during the manufacturing process; if the machine optically scans the part and determines it isn’t up to quality standards, it is automatically rejected. Although this reduces the human labor involved, it still takes a great deal of time to transmit the data to the centralized database and compute engine, which determines the success of the manufacturing process and conveys the result back to the machine. These kinds of delays are a problem even for high-speed networks, as high bandwidth doesn’t guarantee low latency.
The cloud complicates this process further. Instead of sending the data from the device back to the datacenter, it is sent to a remote server that could be thousands of miles away, and, to make things worse, it is sent over the open Internet. However, because of the amount of processing required in such cases, the cloud might be the most cost-effective solution for developers.
Edge computing pushes most of the data processing out to the edge of the network, close to the source (an IoT device, such as a sensor). This model allows us to divide workloads between the data segment (traditionally residing on a public cloud) and the compute segment (near the IoT device). The goal of edge computing is to process the data needing rapid turnaround so it can quickly return results to the device; in this case, the pass/fail results that indicate the success or failure of the physical manufacturing of the auto part. Moreover, the ability to continue processing when communication to the central system has been interrupted.
However, the data should be stored near the device, which is typically temporary, and eventually be migrated to the public cloud for permanent storage. Thus, we replicate processing and data storage close to the source, but it is more of a master/slave type of architecture in which the centralized system ultimately becomes the “source of truth” for all the data, and edge processing is merely a node of the centralized system.
We need a better strategy and possibly an increased investment of time and money in the development process to yield higher-performing and better-designed IoT systems that can cost-effectively handle the IoT’s increasing demands and complexity.
The IoT has dramatically changed the requirements for processing and managing data. Through a common architecture that leverages commodity cloud and non-cloud technology, and that can be easily mapped to existing and emerging technology, we’ll have a solid framework for a more responsive IoT data-processing model that will actually reduce operational costs.
This architecture also must be able to leverage data-response processing, as well as the cognitive computing that exists at the network edge and is therefore closer to the sensors and devices that are being monitored and controlled. Furthermore, for a more responsive use of IoT data, the architecture must bind data directly to rules, policies, and behaviors and be able to drive desired behavior back to the devices (for example, self-healing issues with a jet engine in flight).
In addition, such a system should provide automated learning of data patterns to automatically augment the rules, policies, and behaviors (for instance, the ability to determine the likelihood of a jet engine failure through shared learning models that have experienced thousands of failures and patterns leading up to them).
Moreover, we need to leverage common security and governance procedures and models, as well as common management and usage-based management using inexpensive commodity cloud and non-cloud technology. Finally, this architecture might use containers to encapsulate architecture components.
The resulting benefits will be high-performance data processing, direct behavior interactions, and automated learning that will constantly improve the IoT system’s value.
Physical Database Layer4>
An RDA (shown in Figure 1) uses a common set of SQL and nonSQL (object) data base technology to provide transactional online transaction processing; OLTP) and real-time analytical capabilities. These are a commodity; they should be leveraged using open APIs to allow for easy integration with external applications, and thus shouldn’t be dependent on the databases.
In this architecture, there’s little reliance on proprietary database features, such as stored procedures and triggers. The databases can reside on customers’ premises or in a private or public cloud. IoT data comes from sensors and devices, where the data can be gathered and processed in real time. An example is outdoor temperature data that needs the data response layer to make core decisions on the information from the thermometer (an IoT device) without having to send the data back to the cloud.
An RDA uses special-purpose databases that can provide unique capabilities, such as in-memory data service for ultra-high-performance IoT systems. This is for long-term analytical workloads, and a variety of database components can exist in the model. Data persistence is mandatory. The OLTP database, regardless of the chosen technology, is logically coupled to the data residing at the network edge through abstraction.
Virtual Database Layer
The virtual database layer is a data abstraction layer using commodity middleware that can expose custom abstract schemas and data. The data abstraction approach provides logical binding with the database at the network edge, where data is logically and physically separated and can be accessed from a single virtual schema. This reduces the number of times that the physical databases need to be changed, and places volatility into a domain. Using this approach, only the virtual database not the physical databases— need to be changed to adapt the needs of IoT applications. Finally, these abstract databases can be placed inside containers, based on the needs of the problem domain.
Data Response Layer
This core layer evaluates the data coming from the devices or applications and produces an automatic predefined response from the network edge. Imagine that a jet engine’s temperature reading is 50 degrees over the limit. An automatic rule is invoked: if the data point is out of bounds, the computer responds by kicking off a series of processes that are bound to the data point to bring the reading back in bounds, such as reducing the engine’s fuel flow or revolutions per minute. This occurs autonomously without the need for the centralized processes and data, although they sync at predefined points. The resulting outcome is stored in the knowledge base as a learned response, as well as any necessary changes to the approach that would make for a better resolution to that situation in the future.
There are thousands of permutations just for this one data point, and an RDA can monitor and manage thousands of data points at once. In essence, this layer is a collection of data that can be mapped to different devices, applications, and data persistence layers. The layer focuses on providing automated responses and is able to learn as it processes the response. A machine-learning model is bound to the data points, thus learning through trial and error is an ongoing process.
Data is stored in the abstract (see the virtual database layer), so that the physical database is updated in increments defined by the user. All data received from the sensors is processed at the network edge, though an RDA works with processes and data that exist centrally, such as in a public cloud. The core concept is that the cloud-based components and the components held near the IoT devices and sensors are logically coupled.
The service or API layer is the entry point into the holistic RDA. It provides access to abstract features, such as management by third-party tools or cloud-native features such as raw object storage services or resource provisioning. These APIs are managed using a service directory that includes security and governance for the use of these services and is used from within applications and devices.
Beyond the use of APIs/services, there’s a software development kit associated with these interfaces, and language bindings can be added for different types of applications and devices. Communication bindings are also necessary, including RFID, WiFi, Bluetooth, and so on.
In some cases, services will need to be developed to deal with device limitations, such as the need to constantly poll some devices for new data. An RDA is an event- and service-oriented framework that is extendable using traditional methods, programming languages, and scripting.
An RDA takes existing computing concepts that are trusted and provides a well-structured physical reference framework that developers can use. Each component should be able to work on its own, but by leveraging them together, there’s added value.
As developers are tasked with building IoT systems on public clouds, they’re consistently dealing with performance issues that stem from the cloud platform’s limitations. With an RDA, we can remove these limitations and offer a starting point for building highly effective IoT systems on public clouds, thereby providing a practical solution to this common problem.