Amazon Web Services launched AWS IoT Greengrass in late 2016 as an Internet of Things (IoT) gateway for devices that needed offline, local computing capabilities. As the industry evolved, IoT gateways matured to become edge computing devices. Some of the emerging trends such as event-driven computing, machine learning inferencing acted as key drivers of this evolution.
AWS IoT Greengrass has become a strategic investment for Amazon. Some of the AWS products and services such as Snowball Edge that run on-premises extensively use Greengrass for connectivity and management.
In this article, I will provide the big picture of AWS IoT Greengrass along with the core building blocks of the platform.
AWS IoT Core: The Device Management Service in the Cloud
With IoT Core, AWS got many things right. The platform has a device registry that acts as the secure repository of devices. Based on X.509 certificates, each device is authenticated and authorized before it can participate in a connected solution. Devices connect to the cloud through the AWS IoT Device SDK available for major platforms and languages.
IoT Core comes with a secure and scalable MQTT broker that enables device-to-cloud and cloud-to-device communication. The platform has a robust rules engine compatible with SQL for defining routes and filters declaratively. The rules engine can be integrated with a variety of AWS services including Lambda, which is a critical component of AWS IoT Core.
AWS Lambda acts as the bridge between IoT devices connected to the cloud and the rest of the platform services. Developers use Lambda to integrate sensor telemetry data with Redshift, DynamoDB, and other databases.
AWS IoT Greengrass: Offline IoT Core and Lambda
AWS IoT Greengrass is primarily designed to address offline scenarios. Devices that are originally programmed to talk to the cloud should continue to work even when they are disconnected.
To enable offline functionality, Amazon exposes a compact IoT Core layer with a smaller footprint running locally. AWS IoT Device SDK continues to work with Greengrass when it loses communication with the cloud. Like its counterpart, IoT Greengrass exposes a device registry and message broker to local devices.
Greengrass comes with a Lambda runtime to support event-driven computing. Developers can write code as normal Lambda functions and deploy them to AWS Lambda, which gets pushed to the edge by the Greengrass control plane.
Lambda running in Greengrass provides the required plumbing for the edge computing layer. Since the Lambda functions run natively on the edge, they have access to local resources such as ModBus, CanBus, GPIO, and even file system. Developers exploit Lambda for adding powerful functionality to their apps running at the edge.
AWS IoT Greengrass: Key Building Blocks
Here are some of the key concepts related to AWS IoT Greengrass:
- AWS IoT Greengrass Group: An AWS IoT Greengrass group is a collection of settings and components, such as an AWS IoT Greengrass core, devices, and subscriptions. Groups are used to define a scope of interaction. For example, a group might represent one floor of a building, one truck, or an entire mining site. Since the group acts as the logical boundary for all the devices, it enforces consistent configuration and policies to all the entities.
- AWS IoT Greengrass Core: This is just a device in AWS IoT Core registry that doubles up as an edge device. It is an x86 and ARM computing device running the Greengrass runtime. Local devices talk to the Core similar to the way they interact with AWS IoT Core.
- AWS IoT Devices: These are the devices that are a part of the Greengrass group. Once devices become a part of the group, they automatically discover the Core to continue the communication. Each device has a unique identity and runs AWS IoT Device SDK. Existing devices can be added to a Greengrass Group.
- Lambda Functions: As discussed earlier, Lambda provides the local compute capabilities for AWS IoT Greengrass. Each function running within the Core uses Greengrass SDK to interact with the resources and devices. This SDK abstracts the primitives of dealing with the core runtime, devices, and local resources. Lambda functions can be customized to run within the Greengrass sandbox container or directly as a process within the device OS.
- Subscriptions: AWS IoT Greengrass subscriptions connect the resources declaratively. It maintains a list of publishers and subscribers that exchange messages. A local device may act as a publisher while the Lambda function might be the subscriber. For another scenario, a Lambda function may publish messages to a topic to which the device is subscribed. Subscriptions eliminate the strong dependency between publishers and consumers by effectively decoupling them.
- Connectors: AWS IoT Greengrass Connectors allows developers to easily build complex workflows on AWS IoT Greengrass without having to worry about understanding device protocols, managing credentials, or interacting with external APIs. Based on a declarative mechanism, Connects extend the edge computing scenarios to 3rd party environments and services. Connectors rely on Secrets for maintaining the API keys, passwords, and credentials needed by external services.
- ML Inferencing: This is one of the recent additions to AWS IoT Greengrass. The trained model is first uploaded to an Amazon S3 bucket that gets downloaded locally. A Lambda function responsible for inferencing inbound data stream publishes the predictions to a MQTT topic after loading the local model. Since Python is a first-class citizen in Lambda, many existing modules and libraries can be used to perform ML inferencing at the edge.
In the next post, I will walk you through the steps involved in running a smart camera device at the edge managed by AWS IoT Greengrass. Stay tuned!