This Summer, on June 30, 2023, AWS IoT Greengrass V1 (henceforth, V1) will reach the end of its maintenance phase. But what does this mean? In essence, it means that no updates will be released for Greengrass V1 any longer. This includes updates pertaining to stability, security, and feature updates–none of these will be available after June 30. However, devices running V1 will still continue to operate and be able to connect to the AWS Cloud, and customers with a support plan will continue to be able to open support tickets for Greengrass V1, per AWS documentation.
That said, when AWS “strongly recommends” that customers migrate to AWS IoT Greengrass V2 (henceforth, V2), it is well worth the effort to understand what this entails and then draw a roadmap toward migration if your business has critical workloads running on Greengrass V1. Because AWS already provides a thorough “lift-and-shift” migration plan in their documentation, in this post I will instead focus on re-platforming a Greengrass V1 application to start fresh and fully leverage all the features that V2 has to offer. First, I will clearly delineate the architectural differences between V1 and V2, and then I will present a starter V1 to V2 re-platforming plan.
Applications in V1 are made up of Lambda functions–to run application code–and connectors–pre-built modules used for local resource access, protocol translation, and interaction with external services. V2, by contrast, treats everything as a “Component”–be it a vendor-specific protocol translator, a machine learning model inferencing engine, or a local Lambda function.
Figure 1 - comparison between static application blocks in V1 and dynamic components in V2
Communicationin V1 happens using subscriptions, which are predefined paths to exchange data between Lambda functions, connectors, devices, and AWS IoT Core (through MQTT). Subscriptions are defined at the Greengrass Group level, and a new deployment must be released to add new subscription paths.
V2 overhauls this subscriptions-based mechanism by providing an Interprocess Communication (IPC) system. You may think of this as a data bus shared amongst all Components. Every Component can use the IPC interface to interact with any other Component so long as its authorization policy allows it. For example, a Component whose function is to read data from a sensor can then send its readings to the MQTT Broker Component which then relays the data up to AWS IoT Core.
Figure 2 - comparison of V1’s subscription-based communication and V2’s IPC system
Deploymentsin V1 are an update to a Greengrass Group configuration. That is, you define the settings for the Greengrass Core device–Lambda functions, connectors, subscriptions, etc.–and then apply those settings as a deployment. Updating a Greengrass Group in V1 will update exactly one Greengrass Core device’s settings.
In V2, by contrast, deployments can be deployed to a single Greengrass Core device or to an AWS IoT Thing Group containing multiple core devices. A deployment in V2 is simply a collection of Components and their associated settings.
Figure 3 - comparison of V1’s groups and V2 deployments
The overall pattern here is moving away from having static and prescriptive architectures in V1 towards modularized, highly dynamic architectures in V2. There are a few other smaller changes that you may view in the official V1 and V2 differences guide, but the items above cover the fundamentals, plus a bit more.
Re-platforming Plan
To migrate your Greengrass application from V1 to V2, you may start off with the following steps:
Define what you need your application code to do. Break down the functionality of each Lambda function in V1 and categorize it as a containerized application, script, sensor reading, data processing, or any other categories that make sense for your business use case. You’ll use this definition breakdown to…
Decide how to architect the application in V2. The key thing to understand is that in V1 all application code was managed through local Lambda functions, whereas in V2 you can use Lambda functions, Docker containers, custom runtimes, and even native operating system processes! You’ll have to select which of these to migrate each of your V1 Lambda functions into.
If you need packaged applications (perhaps some that run both in the Cloud and at Edge), Lambda functions or Docker containers could be a good choice to port your code. If you need access to system resources or specialized libraries or applications (such as when you have sensor reading logic that relies on specific application drivers) a system process or custom runtime may be a better fit.
Each of these new application Components will likely need to communicate with each other or with the cloud, so the next step is to…
Draw communication paths between all the new Components. Any subscriptions and data exchange with the AWS IoT MQTT broker are now to be adapted to use the IPC interface. Understand how the IPC works, and determine how you’ll modify your existing V1 application code to leverage it.
One key thing to note is the MQTT broker in V2 is a Component that must be configured to relay messages published locally by client devices to AWS IoT Core–this relay doesn’t happen automatically as it would under a V1 Subscription definition (revisit Figure 2 above).
Develop your first Greengrass V2 deployment with the Components and IPC modifications achieved in steps 1-3. You can start testing it on one of your own Greengrass core devices–or you may set up a development environment on EC2. Once you’re comfortable with your re-architecture, you may begin installing Greengrass V2 on all your devices by following Step 1 in the V1 to V2 upgrade guide, and then releasing your new Components in a controlled (i.e. exponential or max-per-minute) fashion using the new AWS IoT Job configurations now made available to you in AWS IoT Greengrass V2.
What’s Next?
Once you’re done re-architecting your Greengrass application, you will want to begin setting up proper security policies for your client devices, Components, and Core devices, as well as establishing proper device management processes like CI/CD pipelines, deployment strategies, fleet monitoring, and incident response playbooks.
Trek10 is an AWS Premier Tier Services Partner with the IoT Competency. Through our extensive expertise in the Edge and IoT Space and hundreds of clients across dozens of verticals, we can help you design, implement, and deploy solutions for all your AWS IoT Greengrass needs–and more.
