carloscastilla - Fotolia
How to deploy IoT Lambda on AWS Greengrass-connected hardware
Not all Lambda functions are built the same. Follow this advice, and implement best practices to account for Lambda limitations and features in Greengrass edge deployments.
AWS Greengrass Core enables developers to repurpose their Lambda skills to build internet of things applications. But while Lambda functions can be helpful in an edge computing environment, there are some limitations to keep in mind.
In many respects, developers can use the same tools and concepts they use for other Lambda applications to build IoT apps, but there are differences, such as programming languages and support for stateful services. It's also important to test and debug IoT Lambda functions on hardware before deployment.
Fewer languages, more triggers
In the cloud, developers can write Lambda functions using Node.js, Python, Java, C# and Go. At the moment, Greengrass Core constrains developers to Python 2.7, Node.js 6.10 or the Java 8 Lambda runtime. Developers must also package the Greengrass Core software development kit with Lambda functions that run on IoT devices, and it helps to package these apps with the AWS SDK as well to connect with other native services.
As with cloud-based functions, events trigger Lambda functions on Greengrass. These IoT Lambda events could include time-based continuous loops, like background processes that run on an OS. Outside events, such as a call from a web app, can also trigger a Lambda function. A physical button or a presence sensor embedded in connected devices can trigger functions on Greengrass as well -- two examples of how these functions have more trigger options compared to a cloud-based app.
Different types of Greengrass Lambda functions
AWS provides two types of Lambda functions for IoT devices: hardware-based and cloud services-based. A hardware-based function interacts with the Greengrass hardware, and a device fixture, such as a smart camera, can trigger the function. Unlike cloud functions -- which can time out -- these hardware-based functions can run for long periods of time.
A developer can configure this type of function to be in a constant listening mode to respond to new events. For example, a Lambda function that runs on a smart camera on a user's front door could trigger when a visitor approaches. These IoT Lambda functions can interact directly with the hardware or other devices on the same network using the OPC Unified Architecture protocol. Unlike Lambda functions in the cloud, these functions are not stateless, and there is no cost to run these functions locally.
Cloud-based Lambda functions for IoT run similarly to any other Lambda function. Developers can configure these cloud-based functions to interact with data management services like Simple Storage Service (S3), DynamoDB and Kinesis. These stateless functions cannot run forever, which can result in connection timeouts.
Implement IoT Lambda functions
Developers write both types of Lambda functions in the cloud first, and then, they move device-based functions to the Greengrass deployment. This process provides a measure of security and reduces hacking risks from outside the AWS ecosystem. It's a good idea to write local functions to service the needs of the hardware and leave event-driven functionality to cloud-based functions. This reduces the risk of a cascading failure that can start with an IoT device and break other apps -- not to mention drive up AWS costs.
It's important to test IoT Lambda functions, and you can simulate a specific use case for this task. When a Lambda function interacts with hardware, test it against the actual hardware or a device simulator. If you expect to deploy the function to different models of hardware, they should test against those different variations.
You can test cloud-based Lambda functions for IoT devices the same way you test any serverless code. They use the same method signatures for the Greengrass SDK to interact with device hardware and the AWS IoT SDK to interact with the cloud. Developers can write Lambda functions to import the right SDK, whether it runs in the cloud or Greengrass. This makes it easier to run the same code and configurations on the device and the cloud.
Best practices to couple IoT, cloud
It can be helpful to implement a messaging paradigm when you build an event-driven architecture. Greengrass functions on devices and in the cloud both use the publish/subscribe messaging paradigm baked into Message Queuing Telemetry Transport. This enables you to use published messages in the local environment to chain together events between Lambda functions via IoT messages.
Also, establish AWS IoT rules on the cloud side, such as defining functions to debug and capturing messages as they move to and from the edge. Debug rules enable operations teams to send all device diagnostics to internal systems or archive event-driven messages in long-term storage, like S3.
Be sure to take advantage of the existing connection between Greengrass and AWS IoT Core. This ensures that events publish to AWS Greengrass and also travel to AWS IoT Core in the cloud to trigger cloud-based Lambda functions.
This pattern allows two-way integration. It also defines an abstraction layer where the device-based functions don't have to point to all of the cloud-based Lambda functions to trigger them; they just publish or consume events. This helps teams change the implementation on both sides without worrying about how the events travel between them.
