Edge Application Overview

Updated August 01, 2025 19:00

Introduction

An edge application is software created from an edge application image that is available to be deployed on an edge node. After the application is deployed, it’s called an “edge application instance”.

At ZEDEDA, an edge application represents the metadata manifest of the software application. Each edge application comes with its metadata manifest, which is basically a description of the application and a set of instructions for using the application. It’s similar to having a detailed list or a blueprint that explains what the app does, how it should be used, and what it needs to work properly.

Examples of Edge Applications

Video Streaming

One example is software that uses image recognition and identifies if the safety helmet is worn in hazardous areas. This application must get a video stream from an IP camera and process it with image recognition abilities. The required application can be developed using the C# application, .NET framework, or any other platform and packaged inside a Windows 10 virtual machine.

Application to Sense Environmental Parameters

Another example is software that does sensing Environmental parameters and determines the water required for agriculture on any given day. These parameters could be inputs from various environmental sensors like temperature, humidity, or luminosity from the deployed area. The data is then processed to determine the amount of water required to be dispensed. The application could be in python language and packaged as a docker-container application.

Machine Learning Models

Deploying Edge Impulse AI models through the ZEDEDA Marketplace enables you to do secure, single-click deployment of edge AI applications (such as a computer vision application) to fleets of devices. Automatic monitoring of models provides data for continuous model retraining.This example runs on Raspberry Pi 4, packaged as a containerized application.

Edge Application Concepts

Some concepts are covered here, while others are covered in the articles that follow in Next Steps.

Edge Application Types

Edge Nodes running EVE-OS runtime supports the ability to run on multiple computing environments. The type of application in terms of scale, portability, and others will determine the computing environment to choose from. See Manage an Edge Application for supported app types.

Edge Application Images and Volumes

An Edge Application is made up of one or more images. Edge Application Image binary data can be stored in any Data Store. A Data Store captures the location where you want the device to get the binary application images. It can be hosted anywhere. For example, AWS, Azure, GCP, or native servers running HTTPS/SFTP of your choice.

ZEDEDA Owned and operated Data Store (e.g., AWS S3 or Azure)
Customer-owned and operated Data Store inside the customer’s enterprise data center
Public Datastore (e.g., Docker Hub, Azure Container Registry, etc.)

ZEDEDA Cloud itself doesn’t need to have access to the binary data of the images. It only needs the location or path from where it can access the binary data of images. It is the Edge Node, which will access the images for the application to run on it.

Edge Application Runtime Resources

Application developers need to provide EVE-OS information to determine what resources are required for this application to run. An Edge Application explicitly requires one to define how much memory and CPU are required. In addition to that, storage volume requirements can also be defined in the manifest.

ZEDEDA Cloud checks if enough resources are available in a given Edge Node to run the application before placing the application. Besides, EVE-OS also performs runtime checks to ascertain the exact resources required, if available and allocated.

Virtual Machine Managers (VMMs) such as QEMU/KVM require memory to perform their virtualization functions. EVE-OS makes a conservative estimation to accommodate for this VMM overhead for both virtual machine and container applications. This results in additional memory being set aside for a given application instance. To ensure consistent and reliable operations, EVE-OS does not allow oversubscription of memory, i.e. the total amount of memory allocated for all application instances on a node cannot exceed the total available node memory. This means that a conservative VMM overhead may artificially limit the amount of applications/instances that can be deployed on a node.For low memory edge devices or high application count use-cases (such as container deployments), it may therefore be beneficial to optimize the VMM overhead for the application at hand.

The EVE-OS standard overhead currently (subject to change) is defined as:

overhead = 370 MB + 2.5% * application vRAM + 3MB * application vCPU count + 1% of MMIO size (memory mapped IO, dependant on the IO devices mapped into the application)

To override the standard EVE calculated overhead a maximum overhead value can be provided at application or application instance level. Customizing these values will involve trial-and-error. It is recommended not to change the default without thorough testing.

For container use-cases, reducing the overhead to 60-200Mb range may be feasible depending on application specifics.

Note that when modifying the value for a running application instance, the new value will not take effect until the application is restarted.

Edge Application Lifecycle and Management

The management of ZEDEDA Edge Applications involves several critical stages:

Deployment of an Edge Application Instance: After an application image and its configuration (Metadata manifest) are ready, an "instance" of the application can be deployed to specific edge devices or groups of devices. This involves selecting the target devices and initiating the deployment process, which pushes the application and its dependencies to the edge.
Management of an Edge Application Instance: After deployment, ZEDEDA provides comprehensive tools to manage the running application instances. This includes monitoring their status, viewing logs, stopping, starting, restarting, and updating them. This ensures applications are performing as expected and can be maintained remotely.

Edge Application Adapters and Networks

Every application can connect to the external world using a physical adapter or a logical network.

An Edge Node typically has one or more physical adapters, such as: Ethernet ports, COM ports, USB ports, general-purpose input/output (GPIOs), wireless local area network (WLAN) interfaces, Long-Term Evolution (LTE) modems, and more. The Edge Application manifest allows you to define if the application requires that it owns any number of these ports. EVE-OS software then maps the hardware controller associated with these ports directly into the application space. From that point on, the application has full control of hardware I/O spaces and now controls and manages hardware.

In certain cases this is a perfect idea to map the hardware directly into the application, for example:

The Application needs an acceleration engine dedicated to processing like a graphics processing unit (GPU), vision processing unit (VPU), video cards, and more.
The Application uses proprietary protocols that EVE-OS doesn’t understand.
The Application needs a faster transfer rate without taking the hit of going through host OS software.
The application is the legacy mode, and it's easier to map hardware than rewrite it for sharing hardware resources.

Note: EVE-OS can only do physical adapter assignments at the controller level, not individual physical interfaces. For example, if the device has 4 USB ports but only a single USB controller, in that case, all 4 USB ports are given to the application because the USB controller is dedicated.

EVE-OS supports defining various connectivity options like Network address translation (NAT), Switch, a virtual private network (VPN), and Mesh networking. Edge application developers can ask for one or more networks to operate the application. In addition to network requirements, the manifest allows the developer to define a full security policy for network resources and host port mapping.

Host port mapping:
Developers can add a host port mapping rule for the application to connect to the external network.
Security policy:
Developers can provide access lists (ACLs) to receive any connection from an external network. The port mapping details need to be provided if the application needs to accept the link.

Edge Application Custom Configuration

ZEDEDA Edge Virtualization platform uses a cloud-init mechanism to configure edge application instances. Customize the configuration script by specifying User Data in a cloud-config format (cloudinit examples). You can use some of the ZEDEDA platform, Webhook, and User input variables to accomplish the custom configuration task.

You need to define the task in a cloud-init format for Ubuntu or a CentOS type of virtual machine instance. See Customize Edge Application for more details.

For Linux-based containers, you must pass environmental variables to the container to be initialized at runtime. For example, the container may need some configs like:

Where do the log files need to be stored?
Where do the credential files need to be stored?

The environmental variable values can be either given directly or as a variable that can be defined during the application instance creation. This is of the form 'Variable'=<value>.

Next Steps

This is a series of articles. You will likely follow them in this order.

Was this article helpful?

9 out of 9 found this helpful