 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Edge computing is gradually evolving to become the next wave of cloud computing. The new approach solves some of the inherent problems identified with the traditional cloud computing delivery model.
Some of the key advantages of edge computing are:
The best way to visualize edge computing architecture is to think of it as a three-tier architecture. The first tier is the local devices and applications; the second tier is the edge layer, and finally the public cloud as the third tier.
The rise of machine learning is one of the key drivers of edge computing. Public cloud is used for evolving the models that learn from historical data. Edge makes decisions by applying intelligence based on the deployed ML models. The devices take action based on the decisions made by the edge which may include controlling equipment or machinery.
Microsoft was one of the first to offer an end-to-end IoT platform in the public cloud. Customers used a set of cloud services that formed the building blocks of an enterprise IoT solution.
Azure IoT Edge is a recent addition to the Azure IoT portfolio. What was initially built as an IoT Gateway has graduated into a fully fledged edge computing platform. It is placed right in between the devices layer and the public cloud.
Azure IoT Edge is an open source project available on Github. The platform can be deployed on both Linux (ARM & x64) and Microsoft Windows operating systems. Depending on the requirements and runtime environment, Azure IoT Edge can run on a resource-constrained device such as a Raspberry Pi Zero or a powerful x86 server running in an enterprise data center. This flexibility makes it one of the powerful platforms in the industry.
Azure IoT Edge exposes partial functionality of IoT Hub for device authentication and communication of local devices. This is useful in running IoT applications in offline mode without directly talking to the public cloud.
Let’s take a closer look at the architecture.
Azure IoT Edge is designed to be extremely modular and extensible. Microsoft has made some of the decisions that help both the product team and customers in the long term. It is built on top of Moby, an open source toolchain that powers Docker. The platform has a tiny footprint that can be easily installed with a couple of commands.
The devices running edge platforms are often deployed in remote places that are not easily accessible. They need to be registered only during the initial onboarding process after which are remotely managed from the public cloud. If the edge device is offline when applying a new configuration, it gets pushed as soon as the device gains connectivity.
Since edge devices are glorified IoT devices that are capable of running additional services, Azure IoT treats them like any other registered device. The control plane of Azure IoT is used to manage the edge devices at scale.
Azure IoT Edge seamlessly manages the interaction between devices and public cloud. It does all the necessary plumbing involved in authentication and communication among local devices.
Below is a schematic representation of Azure IoT Edge. Let’s understand the role of these components.
These are the sensors and actuators that are responsible for either acquiring the data or controlling a device. These devices are not directly connected to the cloud. Instead, they talk to the local edge computing layer. Azure IoT Edge acts as a transparent gateway that may translate the protocols and data formats used by these leaf-level devices. Each device has a corresponding module registered with the edge layer. These modules are instantiated as containers that are managed by the runtime agent.
Modules are plain vanilla Docker containers that are typically mapped to a device. For example, if there are two devices attached to the edge, a bulb and a temperature sensor, they are modeled as two separate modules containing the communication mechanism and the logic to communicate with the device. Modules are built from standard Dockerfile definitions and pushed to a public or private registry. They cannot be treated as standalone containers because of the dependency on the runtime and context.
Modules can talk to each other through a well-defined interface established by the runtime. Not every module needs to be mapped to a device. For example, a TensorFlow model meant to perform object detection doesn’t have an associated device. Instead, it is daisy chained to a camera module that grabs the frames which are passed onto the next module.
Since modules are a direct representation of devices, they have a digital twin defined as a JSON document. The twin makes is possible to read the last known good configuration and also to set desired properties on the actual device. Digital twins carry additional metadata that’s helpful in querying and filtering devices based on attributes such as location, model, make, and serial number.
Azure IoT Edge treats modules as independent components that are loosely coupled. Similar to UNIX pipes, the output of one module is fed to the another. This design decision makes it possible to define sophisticated pipelines that are modular and extensible.
This is the foundation of Azure IoT Edge which manages the interaction with Azure IoT control plane in the public cloud. Every edge device registered with Azure need to have this component installed. It establishes a secure connection with Azure IoT and sets up the PKI infrastructure required by the security modules. IoT Edge Runtime owns the communication on both sides of the spectrum — devices and cloud. It is installed as a native binary on the target OS such as Raspbian, Debian, Ubuntu, CentOS, and Microsoft Windows. IoT Edge Runtime, which is running as a daemon within the OS, interfaces with Moby to manage the lifecycle of containers deployed as modules.
The IoT Edge Agent is the first component of IoT Edge Runtime that runs as a container. It bootstraps itself each time the edge device is powered on. IoT Edge Agent is responsible for downloading the deployment manifest from the cloud and maintaining the desired state of configuration of the edge device. It pulls all the container images from registries and runs them based on the predefined configuration. Its primary responsibility is to ensure that the state and configuration of containers are matching the original definition associated with the edge device. If a new module is added to the manifest through Azure IoT Portal, the agent pulls the image as soon as it discovers the change. Similarly, it terminates the containers when they are no more a part of the manifest. Behind the scenes, Azure IoT Edge Agent manages the interaction between the cloud and the local runtime to maintain the desired state.
The second component of Azure IoT Edge runtime is Edge Hub that mimics the IoT Hub in the public cloud. It essentially provides offline capabilities of an IoT Hub by exposing authentication and communication services to the leaf devices. A module representing a device has logic to get authenticated with the local hub. Similarly, it can send telemetry data to the hub that will forward it to the upstream components which are other modules defined as a part of the manifest.
Edge Hub exposes the same API as its public cloud counterpart. This design reduces the effort required to refactor devices for the edge. Since it caches the credentials after the runtime gets authenticated during the handshake with IoT Hub in the cloud.
Edge Hub acts as a communication broker facilitating local device communication. It supports standard protocols of IoT Hub including AMQP, MQTT, and HTTP. However, HTTP is not available in the current version of Edge Hub.
In summary, modules are placed close to the devices while Edge Agent and Edge Hub are close to the control plane of the cloud. The runtime manages and orchestrates the workflow involved in connecting the ends of the spectrum.
If you carefully notice, you understand that the Edge Runtime is very similar to a container management platform like Swarm or Kubernetes. Taking advantage of this design, Microsoft has built a Kubernetes connector for Azure IoT Hub, which is based on Virtual Kubelet.
In one of the upcoming articles, I will walk you through the steps involved in deploying and managing edge modules on a Raspberry Pi through Kubernetes. Stay tuned!
