Starter for 10: Meet Jonna Iljin, Nordcloud’s Head of Design
When people start working with Nordcloud, they generally comment on 2 things. First, how friendly and knowledgeable everyone is. Second,...
AWS Greengrass has significantly lowered the barrier for edge IoT development by extending familiar cloud technologies to the edge. Cloud architects and cloud application developers can use their existing knowledge of serverless development and programming languages they already master. In many cases the same exact code can be run both in the cloud and at the edge as a Greengrass Lambda application. This has proven very useful for use cases like KPI algorithms and diagnostic logic that need to be executed both centrally in the cloud and in distributed fashion on the equipment located at the edge.
It’s important to keep in mind that Amazon usually offers the building blocks for making applications, not the actual end-user applications. This also applies to Greengrass and AWS IoT in general. You get an extensive set of features for building IoT applications, but you still need to put them together into an application that solves the business case requirements. Amazon calls this eliminating the “undifferentiated heavy lifting”. Application developers don’t have to deal with low level issues like scaling databases or designing communication protocols which have already been solved in general. Instead they can focus on implementing the business-specific features and logic relevant to the use case.
In fact, as the AWS IoT platform has evolved in recent years, the need custom databases has been almost completely eliminated. AWS IoT Device Management provides a flexible way to organize IoT devices into groups and hierarchies. Custom metadata can be attached to the devices, enabling indexing and searching. You no longer start a project by designing database tables from scratch, but instead you first look at what AWS IoT already offers you out-of-the-box.
The same principle applies to business logic. In many cases there is no need to write custom code, because AWS IoT’s MQTT based messaging platform offers simpler ways to filter, route and process data. This is particularly important for datalake solutions, because the amount of data processed can be quite large. If you can completely omit custom code, you don’t have to worry about scaling it. The best datalake solutions simply connect a few services like AWS IoT, Kinesis Firehose and Amazon S3 together, and the data is automatically collected into S3 buckets regardless of its size and bandwidth.
In the case of Greengrass edge solutions you still usually need Lambda functions to implement business logic. Greengrass contains functionality for topic-based MQTT routing, but to process the contents of MQTT messages, some code is needed. However, the implementation can be just a few lines of code to execute the required algorithm as a Lambda function. Developers don’t have to worry about building containers, opening network connections or configuring security settings. Greengrass takes care of all the details of deploying the Lambda function.
It’s worth noting though that larger customers usually prefer to build a customized management system on top of AWS IoT and Greengrass. There are lots of exposed details and moving parts when dealing with “raw” AWS IoT devices and Greengrass deployments. When a lightweight business-specific management layer is built on top of them, end-users can deal with familiar concepts and ignore most unnecessary details. Power users can still access the underlying technologies simply by using the AWS Console.
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.