Design Principles for Edge Native Applications

The definition of Edge Native given above sets a strong focus on the autonomy afforded by programmable edge devices, it is thus intended as a clear delineation from other approaches that include central components. Cloud Native applications make good use of the reliable offering of centrally managed and deployed services within the environment specifically created to this end by cloud data centers. Where reasonable and affordable, this environment can be replicated on-site, with the same benefits, but also with the same drawback in terms of local autonomy: the function of individual devices hinges upon the reachability and availability of central components. Where such a single point of failure is unacceptable, Edge Native provides the answer.

The structure of IoT deployments today is rooted in a cloud-based architecture as well, where edge devices perform only limited processing while the focal point for data collection and decision making is centralized. This is usually achieved by deploying a broker within the local network — presenting straight-forward service discovery as well as a single point of failure — and having that broker connect to a Cloud Native application; it can, therefore, be characterized as Cloud Native with outposts. This shares the same characteristic of centralization with Cloud Native that distinguishes this approach from the uncompromising resilience required by true Edge Native applications.

In general, Edge Native applications do not require any central component, not even a centrally provided network infrastructure. They still work when all they can do is reach physically neighboring devices via local radio connections like Bluetooth, Zigbee, or ultra-wideband (UWB). Since this is a significant restriction, Edge Native applications will often be complemented by Cloud Native or IoT applications for those parts of the overall system functionality that do not require local resilience or that naturally belong to the cloud.

It lies in the nature of Edge Native applications that the programmer cannot rely upon several common approaches employed in classical desktop applications or cloud services. In particular:

From these constraints, it follows that Edge Native applications are built on a programming model that acknowledges the fact that decisions must be based on the incomplete information that is locally available, and therefore, might need to be revised later if they are recognized as faulty.

Much of the effort in creating Edge Native applications goes into the proper design of communication protocols between different apps as well as between instances of the same application on multiple devices. The flow of information needs to be shaped such that the aforementioned programming model can indeed allow the best possible decisions to be made with local knowledge, keeping in mind potential conflicts to be detected and remedied.

The resilience in Edge Native applications is achieved by a higher degree of redundancy, the same information is replicated on many devices to allow timely usage in the face of unreliable communication. This principle successfully works in all biological systems, down to the DNA.

It is also often helpful to run the same inference algorithms multiple times, wherever they are needed, instead of relying on a single location and spreading the results; this mirrors the simultaneous observation and analysis of a traffic situation by all involved car drivers.

As such, these constraints bring the creation of Edge Native application closer to how we would think about formulating processes among groups of humans, taking away some of the convenient higher-level abstractions we are used to in the cloud and making the design more tangible.

The Reactive Manifesto was written in 2013 with Cloud Native applications in mind; its main point was to acknowledge that we need a truly distributed application design in order to realize the gains offered by cloud infrastructure. The core tenets of responsiveness and resilience directly apply to Edge Native applications as well, which are naturally message-driven, while elasticity plays a different role: due to their local nature and their focus on peer-to-peer communication Edge Native applications are inherently scalable — even globally — as long as the locally necessary information for taking decisions fits on each host device.

Since many of the core principles and design patterns of Reactive Systems have a strong relationship to distributed systems and Edge Native applications are the ultimate form of distributed computing, it comes as no surprise that the Reactive Principles inherently apply to them as well.

Our greatest achievements in providing complex cloud services in a reliable fashion will need to be matched with Edge Native applications that provide ultimately resilient local services. For this to succeed we must avoid an impedance mismatch between these two quite different software environments: the integration and information flow between edge and cloud needs to be straightforward so that it can be dependable as well.

To this end, the innate confluence of the constraints and principles for Reactive Cloud Native and Reactive Edge Native applications is extremely fortunate. Both classes of applications:

In summary, Edge Native applications need to be Reactive, perhaps even more so than Cloud Native applications, and both of these profit from the symbiosis afforded by this common foundation.

Next, read about the Reactive principles and patterns that will help you achieve Reactive benefits in your Edge Native application.