AWS Greengrass is an open-source edge runtime developed by Amazon Web Services which consists of pre-built software components to manage software on a large fleet of Linux IoT devices. The latest revision is Greengrass v2.0, which is the successor of the initial Greengrass runtime. This was released on the 15th of December 2020.
The AWS IoT Greengrass product came to close the gap of managing embedded Linux based products — basically, tomorrow’s every smart connected device, from robots, smart AI city cameras, electric motorcycle, mall smart screen, ATM or even healthcare devices and manufacturing machines. But it seems like Amazon has missed one of the most important aspects of managing edge embedded Linux based products.
In the software and embedded systems industry, it is key to manage smart connected devices remotely to avoid any hardware or software bugs that may cause unstable behavior in the deployments. Tech companies like Amazon, Facebook, or Google always deploy new code to production (as often as once every 11.7 seconds on average, according to Newrelic), to add new features and solve production software bugs. This agile effect is expanding towards every other company in the world that produces and deploys smart devices; not just computers; Embedded Linux Devices.
AWS completely skipped the fact that embedded Linux devices are different, and here is why:
While cloud server resources and software support are limitless and can be changed or upgraded with a click of a button, when it comes to devices running on the edge, things take a hard turn and the physical device limitations and costs start to cause trouble.
Unlike deploying one or two devices, when developing thousands or hundreds of thousands of edge devices, the cost per hardware unit can’t be taken lightly. A simple upgrade that’s worth a few cents can add up to sometimes in the hundreds of thousands of dollars, and it’s something you will have to calculate one way or another. Single-board computers or System on Modules price starts as low as 7$ per unit, with low resources as 1 CPU core, ~60MB Ram, and ~60MB Disk options. From smart washing machines to mobile computing devices, edge devices are everywhere around us today.
That’s exactly what the AWS IoT Greengrass team has apparently failed to address.
Embedded Linux devices, unlike full-fledged desktop computers or laptops, are smaller footprint devices and have a very limited amount of resources to work with. For the IoT devices that use them to be cost-effective, they must stay that way. This obviously means that whatever the software/firmware/operating system that is being designed to run on must be resource-efficient; not to mention the software applications that run within those operating systems.
However, the Greengrass agent requirements are totally out of scope for Linux based devices. Their edge device core agent is written in Java (Yes, of all other language options, they chose to go ahead with Java.), which means that the Java runtime environment must be installed on the edge device and a minimum of 256MB disk + 128MB ram available space for the core Greengrass agent to run. No typos here, that’s the number: 256MB of disk space and 128MB of RAM. And as the official website mentions, “this doesn't include components deployed to the core device”.
Even on a fairly-powerful embedded device that has around 1GB of disk space, as AWS states, their Greengrass IoT core uses up a quarter of otherwise extremely useful storage space. Why would something that's meant to be doing only one thing; communicating with the cloud, have to be provided with so much system resources?
We took a simple yet realistic IoT use case and tried to figure out how challenging it could be to use the Greengrass core software. Well; a good amount.
We are living in the days where IoT projects are getting into many different industries to solve daily, real-world problems. Local cities, for example, now want to monitor their citizens to maintain law and order. This is already being realized thanks to smart city cameras that analyze people's behavior in the street and sends alerts of accidents and unusual cases to the local police. By doing the software calculations on the edge, the camera will only need to send back minor data results instead of streaming 24/7 full HD video from thousands of cameras to the cloud for further study. To be able to do this in a cost-effective manner, processing power should be utilized to the maximum, and using a runtime that does not contribute to the actual video processing which also takes up a fair amount of RAM and disk space only makes the system more inefficient and ultimately, begs for more resources to give a better throughput.
Considering that fact, when developing such sophisticated products, there are many aspects that need to be considered, especially the plan to cross hundreds of deployments per year.
Yes, it’s true that Greengrass is more than just a device management platform, a runtime that connects the edge to the cloud which opens a whole new level of processing power. But, ask yourself; when it comes to space and resource-constrained system, is it really worth it to implement such a heavy ecosystem just to monitor and control your devices?
To make matters worse, they picked Java.
Choosing to build an edge agent with Java, basically complicates all three aspects of edge agent design.
A proper edge device agent should be:
Generic — run on any Linux based device, CPU architecture, and environment.
Lightweight — remember, you are not the product app, you’re just an add-on that grips the device managed.
Stable — the edge agent shouldn’t have hard dependencies, if those crash, the edge agent might also crash, leaving us with zero access to our edge devices.
Amazon Greengrass IoT core agent does not properly address those three main aspects, rather following their own way of doing things. If you are to take a look at the installation guide, you may get an idea of how complicated this whole ecosystem is.
Had AWS gone with Go, C++, Python or Rust, the first two points would have been much easier to address.
Can we do things differently?
Simple answer: YES!
Here at Upswift.io, we are working with companies all around the world, coming from a wide range of industries, building smart gateways, robots, and smart screens. We learned the hard truth of the embedded market and designed a solution that puts the fleet owners in the front.
We know how difficult it is to develop a smart product that is going to be deployed far from your access. That’s why we built Upswift platform: an all-in-one platform that turns your edge devices into managed ones in any application you can imagine.
Top comments (0)