When Jonas Bonér, Lightbend’s Founder and CTO, and I were chatting earlier in 2023, he shared his idea to unify the programming experience between the cloud, the cloud edge, and, ultimately, devices physically located away from the cloud; the “far edge”. This is a powerful concept that empowers developers to build solutions that span multiple and often different environments.
Jonas wanted us to bring our experience working at the far-edge these past 5 years, and port the aspects of Akka, which I will expand on through this post. He also invited us to express this port using Rust, which we have been using over the same time, given its suitability to the edge. This appealed to me because I have been an advocate of Akka for a long time, but also because it would help me formalize our practices and provide a stronger toolkit for us to leverage in our future projects.
What emerged is Akka Edge Rust which brings two important and successful aspects of Akka to the far edge:
Before delving into what Akka Edge Rust is, allow me to set the scene on what we have been doing over the past 5 years as it’s relevant to the work I’ve been doing on it and explained below.
I used to work at Lightbend and left to pursue solutions for Agriculture and Energy. I have been developing products and services for both. For example, Cisco Inc. wanted to develop a “decision platform” for farmers to extend their reach from the data center to the edge and funded us to do it. Farms are often remote, suffering poor network connectivity and unstable power supplies. These environments quickly defined what edge meant to me. It is fair to state that network connectivity has improved over the years, but it only has to fail once to become an issue.
The power situation has also improved given the increased use of solar and battery, but it still fails. My first company, Titan Class P/L, was spun out of Cisco, and we quickly learned the difficulties in squeezing the Java Virtual Machine (JVM) into the 1GiB of memory of Cisco’s popular IR829 edge gateway device. The JVM also struggled to perform on its single-core Atom processor, particularly given the demands of Just In Time (JIT) compilation. That said, we managed to run several JVM services in less than 512MiB—so it is possible. I do not recommend trying, though, as there are easier paths, as we will discuss.
Despite the discoveries of our initial approach to implementation, treating the network opportunistically and becoming conscious of energy consumption proved useful. The design was good. We could reliably store and forward data gathered from a multitude of sensors around the farm, including water tank levels, water pipe pressure, electric fence measurements, and more. When there was a network outage, the farmer would not lose these observations.1
Aspects of this system gradually became written in Rust for gains in efficiency. Back then, things were much less mature in Rust-land, but the language was solid, and the community was supportive. Rust allowed us to reside on these resource-constrained devices more easily and consume less energy. On the latter point, heat is the enemy of good regarding hardware. The cooler we can run the software and its hardware, the greater the reliability we can achieve.
Over the past two years, we had the opportunity to move into the energy business and make our hardware. We were invited to build an electric vehicle (EV) charging system from the ground up and form a new company. Cuprous P/L was born with a focus on facilitating the transition from fossil fuels to renewable energy, bringing a blended approach to software and hardware development. And clearly, we were going to operate at the edge. This time, though, the edge is running software inside the switchboard of a building. We developed software that observes a building’s load and controls EV chargers to deliver specific allocations of electricity to an EV in near real time. The software must continue to run without requiring additional cooling (heat is the enemy of good, right!). If the internet is not available, then our system must continue to function. Otherwise, EVs do not get charged, which does not tend to make their owners happy2.
Although the domains of agriculture and energy are quite different, the technological approach we adopted has been the same. Provide autonomy at the edge, embrace networks failing, and run hardware and software efficiently.
For servicing both the agriculture and energy scenarios, we developed a toolkit and named it Streambed. It was originally developed for Cisco using Akka Streams and Scala and, therefore, ran on the JVM. Over time, we have ported all of it to Rust and made it open source. Streambed provides a miniaturized commit log in the style of Apache Kafka, focusing on managing small amounts of storage. Streambed also provides a secret store in the style of Hashicorp Vault but for running in a resource-constrained environment. Streambed has been integrated with Akka Edge Rust, and we welcome its use, noting that we depend heavily on it for our production systems. Streambed is tried and tested.
While we have been using event sourcing and persisting events via Streambed, it became apparent that we could benefit from formalizing the concept of an entity and how that entity may produce and consume events with cloud-based services, particularly where connectivity is less reliable and potentially more costly in terms of bandwidth. Akka Edge Rust formalizes these concepts by bringing in Akka Persistence and Akka Projections.
The choice of Rust for Akka Edge is directly related to our learning that a strong community, resource efficiency, and a focus on writing high-quality software are very important when targeting the edge. And did I mention that heat is the enemy of good? Aiming to write software that avoids hardware requiring a fan not only promotes reliability but is also more financially economical to run. Our reference architecture for Akka Edge Rust is our Cuprous Secured Edge Gateway, a single-core 500mHz MIPS32 microprocessor running Linux with 128MiB of memory and 32MB of storage. Devices with more or less of these specifications can be accommodated, noting that the smallest Raspberry Pi Zero has double the CPU speed and a quadruple amount of RAM.
Akka Edge will naturally scale up with more cores, memory, and storage, but the benefit of targeting smaller amounts of resources means that larger amounts of resources become available. It is possible to apply Machine Learning models at the edge in conjunction with Akka Edge and the hardware being discussed.
And for me personally, working with the Akka team on Akka Edge has been wonderful. The immense knowledge the Akka team has gained from building and running distributed systems over the years has certainly influenced the design decisions made with Akka Edge. Although Akka Edge is a new technology, its design and foundational technology are mature and proven.
Our projects in agriculture and energy are underpinned by Streambed and, moving forward, Akka Edge Rust. We have already begun work on our next edge-based project, a Home Energy Management System (HEMS). The energy industry loves acronyms!
The HEMS will leverage a new version of our edge gateway hardware and software based on an Arm Cortex-A5 chip. It will run services written using Rust and perform activities such as preventing the export of solar power to the grid if the grid is already overloaded. Similarly, we will coordinate our EV charging system with the home battery so that the latter does not discharge while charging an EV (there is no point; home batteries have much less storage capacity). And coordinating other appliances such as heat pumps, pool pumps, air conditioning, and more. Akka Edge for devices will be at the center of these activities, running on a small device located in a building’s switchboard.
We have also had some other interesting projects proposed over the years. One in particular involves instrumenting a sub-antarctic island south of New Zealand. While I am still determining whether the project will ever actually happen, I feel confident that the approach we take with the edge will be suitable for the harsh environment that we would have to endure. Again, there is poor network connectivity and a scarcity of electrical power. Akka Edge Rust will be perfect for this scenario.
And then who knows beyond that… Antarctica, The Moon, Mars… someone has to do it. Perhaps Akka will then edge even further and reach Mars one day…
To start exploring and working with Akka Edge Rust, see the Documentation for samples, programming model and API, in-depth explanation of concepts, design, and deployment models, and the GitHub Project for the source code and issue tracker.
Try it out and let Lightbend know what you think. Lightbend would love to hear from you. Please post your comments or questions in the Akka Discussion Forum.
Akka is released under the BSL (Business Source License), which is free for smaller companies. If you are interested in discussing a commercial license, please contact Lightbend.
1 If you are interested, we built LoRaWAN gateway towers and collected data from sensors located up to 10km away. The sensors themselves run for about two years on one or two small batteries and transmit their data once every hour or two. The payloads delivered are sub 20 bytes.
2 In North America, about 55% of public charger infrastructure is unavailable due to network connectivity issues. This is not necessary, and it is almost always down to poor design. Ref: https://www.caranddriver.com/news/a45309960/ev-charging-stations-problems/.
