Why I Like Modeling IoT Devices with Azure Service Fabric Actors
Why I Like Modeling IoT Devices with Azure Service Fabric Actors
Service Fabric Actors offer a simple, reliable programming model to efficiently act as an IoT Device Shadow. Device Shadow is the concept used when a software entity (a class, a service, etc.) is used to contain the recent state of an individual remote IoT device. By “state” I mean the current data that an IoT device is designed to furnish to an IoT system. For example, the state of a remote oil temperature sensor device would be the current temperature of the oil it is monitoring. Device Shadows are often implemented with a JSON document, but here I use Service Fabric Actors.
Essentially, a Device Shadow is a virtual representation of a remote IoT device. It contains the persistent recent state of the device. A Device Shadow is used by the rest of the software system in an IoT solution to access a device’s state to avoid a time consuming and resource expensive process of gathering the state information from various places in an IoT system, perhaps including a trip all the way out to the remote IoT device to get it’s state. Continuing the previous example, with a Device Shadow for an oil temperature sensor device the software does not need to ask the sensor device directly for its current measurement. Nor does the software have to do a series of database queries to get the current state of a device saved in disk storage. Rather, the software can simply query the associated Device Shadow instead, since it contains all of a device’s recent state in one place. This assumes the rest of the system is designed to have the IoT devices periodically report their state to their Device Shadow ― A standard practice. There may be dozens to 100s of thousands or more of remote devices and their Device Shadows in an IoT System! The ability to deal with such massive scale is extremely important here.
Service Fabric is Microsoft’s next-generation middleware platform that has strong support for high scale microservices. And it is aimed at providing very high reliability achieved by having multiple replicas of each service it hosts running on multiple virtual machines that make up a Service Fabric cluster. Only the “primary replica” is used, but the “secondary replicas” in standby on other virtual machines in the cluster have their state always kept up to date with that of the primary replica. This allows for very quick and precisely accurate automatic recovery from a crashed virtual machine in the cluster. No operator involvement is required for this recovery.
A Service Fabric Actor is a highly reliable, single threaded, persistently stateful microservice that runs in a Service Fabric cluster. Actors support high scale and high reliability since each one is a special Service Fabric Reliable Stateful Service that runs under control of the Service Fabric Actor Service which provides them with the unique characteristics of Actors. Thus, SF Stateful Actors are very well suited to act as a Device Shadow. And, since they are individual microservices, they can scale out without a negative impact on the code, operations, or performance of the overall software system.
Here is a conceptual data flow diagram showing how Service Fabric Actors can implement the Device Shadow role in an Azure IoT solution.
I have omitted detail in Figure 1 so as to focus only on the Actors and the flow of commands, command responses, and telemetry in the solution. Please see “ Microsoft IoT Reference Architecture ” for definitions of terms used above.
The Business Backend System (Backend for short) is responsible for the UI display of alerts, dashboards, visualizations, and reports, plus some analysis of data, provisioning the system’s resources, and monitoring the health of the system as it runs. The Backend also is responsible for issuing commands to remote IoT devices through Device Shadows as directed by user interaction with the UI or a via a programmatic workflow. The Device Shadow Actors are intermediaries, standing between Backend System and the Cloud IoT System (with its IoT Gateway data ingestion buffer to which the IoT devices connect).
During December 2016 and January 2017 I implemented an exploratory proof of concept (POC) system that used SF Stateful Actors as Device Shadows. A challenging feature of my POC is that it had a requirement to implement significant commanding from the Backend System to the IoT devices. Specifically, I had to make the IoT devices start, stop, and when running put them online and take them off line. Commanding devices entails a lot more than just passively collecting telemetry from sensors, as is common in many IoT solutions.
Commanding involves the Device Shadows maintaining the command state of a remote device, in addition to its telemetry state. It also requires a Device Shadow to implement behavior to support commanding. Specifically, the Device Shadow must receive a command from the Backend System and then send the command to the correct remote device, allowing time for the device to execute the command, and then receive a command response from the IoT device when the device has completed command execution. In addition, the Device Shadow needs the ability to time-out when no command response is received within a specified time. And, the Device Shadows must know when a command is in the process of being executed by a device so as to prevent attempts to have the device execute multiple commands concurrently. Finally, in all of the above scenarios a Device Shadow Actor must notify the Backend System of the command state at critical junctures in the commanding process, e. g. normal command completion, command time out, device error, etc. These command response notifications allow the Backend to push them to UI client’s for alerts and dashboard updates.
Service Fabric Stateful Actors offer a great programming model to efficiently act as a Device Shadow that models the telemetry and command needs of an IoT device, to allow it to work well with the Backend System as well as other parts of an IoT solution. As such, SF Actors speed up development time, plus reduce the level of skill required to effectively program and debug potentially complex logic associated with commanding and telemetry.
Keep in mind, with many cloud solutions there is usually no guarantee that difficult problems will not arise when scaling out to 1) service tens of thousands or even millions of IoT devices, or to 2) service high data rates moving to and from the devices. Such problems often involve throughput and contention issues in accessing storage, the need to use multi-threaded programming techniques, excessive latency, and the need to orchestrate the timing of several different collaborating components in a cloud environment which is eventually consistent by its nature. Any of these issues by themselves is a challenge to a seasoned developer, and taken together they will likely take a substantial amount of time to get right. My POC showed me that Service Fabric Stateful Actors can relieve a substantial amount of this burden in the realm of Device Shadows.
In what follows I list what I liked about developing my POC with SF Actors, followed by a list of links that facilitate you learning more about Actors and Service Fabric, rather than explaining them in this blog.
Why I Like Service Fabric Actors as IoT Device ShadowsMost of the behavior required for Device Shadowing is located close together : It is in the Actor microservice itself or in the resource accessor used to provide system wide access to an Actor. Not much of this behavior is spread widely across the entire system. This reduces development and maintenance time. There is no need to de
本文系统（windows）相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术
本文标题：Why I Like Modeling IoT Devices with Azure Service Fabric Actors