AWS IoT Greengrass

AWS IoT Greengrass

AWS IoT Greengrass is a cloud service and open-source runtime for IoT devices that extends AWS cloud capabilities to local devices. Greengrass allows AWS functionality like Lambda functions to run on distributed apps. Local IoT devices can then continue to function even with an unreliable connection to the cloud. Additionally, Greengrass provides pre-built, modular components for app development.

In this article, we’ll explore the benefits and drawbacks of AWS IoT Greengrass. We’ll also provide you with tips, best practices, and AWS IoT Greengrass alternatives.

Executive summary

Let’s review the pros and cons to convey a simplified idea of what territory we’ll be covering:

Benefits of AWS IoT Greengrass

In this section, we’ll explore features that make AWS IoT Greengrass a popular solution for “edge computing”. We’ll also look at use cases where Greengrass’s technology struggles to meet a common need of IoT developers, and suggest newer alternatives as needed.

Modular development

Most IoT apps have to address many of the same challenges. As a result, reusability is a top concern for cloud service providers targeting the IoT space, and Greengrass is no exception.

AWS IoT Greengrass provides prebuilt components for integration with CloudWatch for monitoring, IoT Device Defender for security, an array of machine learning components, and several other public components.

In addition to using public components, Greengrass lets you create custom components that can integrate with AWS IoT Core. The deployment and dependencies of the actual code for the component are managed by a JSON/YAML file called a “recipe”. For example, a “Hello, World!” app written in Python and meant to run on an IoT device with Windows might have a recipe like this:

Edge computing

Edge computing is a framework that brings compute and storage closer to the data source. By offloading processing from the centralized cloud to the edge, this can reduce latency for IoT local devices within your network. Edge computing is also a great usecase for devices that require exceptional reliability, even if the network connecting the device is intermittent.

Devices are built, deployed, and managed with Greengrass, but process and manage their own data directly. (Source)

For the booming Industrial IoT (IIoT) space, edge computing has become a core functionality and is expected from any enterprise IoT cloud service provider.

Getting started with Greengrass

Before committing to any service,you want to ensure it’s the right solution to manage your infrastructure. Let’s look at the prerequisites for Greengrass, as well as the kinds of architectures that benefit from it the most.

Prerequisites for working with Greengrass

For a device to work with Greengrass, it must have:

1. A supported operating system (Windows or Linux),
2. A Python 3 interpreter (3.5 or later).

Both of these requirements must be available on the IoT device. For example, an ESP32 won’t work with Greengrass because its barebones Mongoose OS isn’t compatible. On the other hand, a Raspberry Pi running Linux works just fine.

AWS IoT Greengrass use cases

Greengrass is well-suited for scenarios where devices are built with AWS functionality in mind. For these devices, Greengrass helps them operate resiliently without consistent network access.

Imagine a marine biology expedition designs an underwater drone to survey the seafloor. Onboard IoT systems for sonar, photography, and navigation have their own apps and functionality. Sometimes, the drone tries to connect to the internet to report to the human team above the sea surface, but the onboard devices must be in continuous communication and work even if they can’t connect to the internet when they’re deep underwater.

Rudimentary underwater drone IoT network architecture.

The devices themselves use local lambda functions and communicate with each other (and to the crew) via a router that sends a signal to the surface.

This scenario perfectly highlights what Greengrass is good at: making AWS cloud functionality usable for IoT devices that might not always be able to connect to the cloud.

What if we needed to redeploy to fleets per region, with different restrictions based on local regulations? In that case, a service with more sophisticated geography-based features might be more appropriate. Similarly, if we were stuck with a C-based microcontroller and no OS, Greengrass would not be an option.

There are also use cases where Greengrass is overkill. IoT systems that have reliable connections and serve a non-critical function probably don’t need Greengrass. For example, a smart fridge in an urban office that reports usage statistics to the office management can do without it.

AWS IoT Greengrass limitations

In the previous section we looked at some technical challenges of Greengrass. Now we’ll look at limitations put in place by Amazon for business reasons, such as quotas and pricing model. None of these issues are intrinsic to Greengrass’s technology. However, they are practical considerations for engineers that need to operate within budget constraints.

Quotas

AWS is very strict about Greengrass quotas. For example, there is a hard limit of 5,000 components per region. API operations are limited to 30 requests per second per region. There are many more such restrictions and the full list can be found in the AWS IoT Greengrass V2 endpoints and quotas docs.

Geo-replication

Suppose you are a manufacturer who wants to start up a new factory in a new region and need a fleet of IoT devices for your plant.

How can you manage the replication of your current architecture to the new region, while also adjusting the infrastructure to meet your needs? It isn’t impossible in Greengrass, but AWS doesn’t provide any way to do this out of the box.

This goes for geography-sensitive functionality more generally, like pinning data to a specific region and fencing data into a specific geographical region. It’s not impossible in AWS, but you’ll have to implement most of the functionality yourself from scratch.

Onerous additional charges

The AWS IoT Greengrass pricing model often surprises developers. Don’t commit to Greengrass until you’ve carefully estimated your feature, resource, and bandwidth requirements and compared your calculations with the pricing information found here.

There are additional charges for using Greengrass with other AWS services, the number of connections, and much more. In practice, it’s difficult to determine how much you’ll pay, because many sections link to other pricing pages, which in turn point to other pages.

AWS IoT Greengrass Best Practices

Now let’s review some AWS IoT Greengrass best practices. These are tips and advice for avoiding mistakes and successfully adopting and implementing Greengrass.

Use v2

In 2021, Greengrass announced a new major version release that included breaking changes for a lot of core functionality. v1 is deprecated and there is no reason to use it unless you’re interacting with a legacy app that would be infeasible to migrate to v2.

Follow the official security guidelines

AWS maintains an up-to-date list of security best practices for Greengrass, which can be accessed at the page Security best practices for AWS IoT Greengrass.

It’s a small doc - go through the list before developing a Greengrass to make sure you don’t later violate an important security principle.

Prefer prebuilt components

As the old engineering proverb goes, “don’t reinvent the wheel.” If prebuilt Greengrass components can be combined to accomplish something that is good enough for what you need, it’s probably best to use those and not try to build a custom solution.

Beginning of the list of Amazon’s first-party pre-built components from their docs. (Source)

Of course, there are times when gluing together pre-built components is not an option and you simply must create a component completely from scratch. In those cases, you should consult the official AWS developer guide for custom Greengrass component development.

Conclusion

The introduction of modular, cloud-driven IoT developer services, like Greengrass, was a massive leap forward from the way IoT development was done just a decade ago. The dark days of custom OSes and writing on-device code entirely in C (if you were lucky, otherwise assembly language!) were not that long ago.

Greengrass, along with a slew of related IoT Developer Experience (DX) innovations, changed the marketplace and paved the way for newer technologies. Now, any app developer can write code for IoT without knowing the ins and outs of memory management in a low-level language. Instead, enterprise IoT app developers can worry about what matters: creating reliable apps with a fantastic user experience.