EDGELESS Reference Implementation

This repository contains a research prototype of the EDGELESS platform, which is under active development within the project EDGELESS.

There currently are no guarantees on Stability and API-Stability!

Introduction

EDGELESS is a framework that enables serverless edge computing, which is intended especially for edge nodes with limited capabilities.

An EDGELESS cluster consists of one or more orchestration domains (three in the example figure above) managed by an ε-CON (controller).

Users interact with the ε-CON to request the creation of workflows. A workflow specifies how a number of functions and resources should interact with one another to compose the service requested by the user by sending to one another asynchronous events that are akin to function invocations. Functions live entirely within the realm of the EDGELESS run-time, while resources may interact with the external environment, e.g., handling events in a resource may have a side effect, such as updating an entry on an external in-memory database or reading the value of a physical sensor.

Currently supported resources:

• http-ingress: to ingest of HTTP commands from external web clients;
• http-egress: to execute HTTP commands on external web servers;
• file-log: to save to a node-local file strings, optionally with timestamps;
• redis: to update a value on an external Redis server.

Functions are stateful: a given function instance is assigned to exactly one workflow, thus the function developer may assume that data will generally remain available across multiple invocations on the same function instance. However such state is:

• tied to the specific instance: if there are multiple instances for the same function, then there is no consistency guarantee across the multiple states;
• ephemeral: if a function instance is terminated, then there is no effort to save/persist the state.

Furthermore, unlike many other serverless computing platforms, workflows may consist of a wide variety of function compositions, as illustrated below.

An orchestration domain contains:

• one ε-ORC (orchestrator) that manages the scaling of function instances and resources within its domain;
• one ε-BAL (balancer) that plays two roles: 1) realization of an inter-domain data plane, to allow events generated by a function instance in an orchestration domain to be consumed by a function instance in another orchestration domain; 1) configuration and management of the resources;
• one or more nodes, which can host the execution of function instances of a given workflow in a WebAssembly run-time environment or as a Docker container.

The byte code of the WASM function instance or the name of the Docker container to be started is provided by the user when requesting the creation of a workflow, which also includes annotations to specify the Quality of Service requirements (e.g., maximum completion time) and workload characteristics (e.g, average invocation rate), as well as affinity of functions to specific hardware properties (e.g., GPU required) or preference for other system parameters (e.g., location, owner, price). Depending on the annotations, the set of active workflows, and the current system conditions, the ε-CON may reject the workflow creation request.

Some components/features are illustrated separately:

• Orchestration model
• Support of Docker containers

Known limitations

Currently there are several known limitations, including the following ones:

• the dataplane within an orchestration domain is realized through a full-mesh interconnection between all the nodes and the ε-BAL;
• the ε-CON only supports a single orchestration domain and does not perform any kind of admission control;
• no workflow-level annotations are supported;
• the payload of events is not encrypted;
• the configuration of the ε-CON, ε-CON, and ε-BAL is read from a file and cannot be modified (e.g., it is not possible to add an orchestration domain or a node while running);
• there is no persistence of the soft states of the various components.

The full list of issues is tracked on GitHub.

Stay tuned (star & watch the GitHub project) to remain up to date on future developments.

Repository structure

How to build

See building instructions.

How to run

It is recommended that you enable at least info-level log directives with:

export RUST_LOG=info

To get the basic system running, first create the default configuration files (they have fixed hardcoded values):

target/debug/edgeless_inabox -t 
target/debug/edgeless_cli -t cli.toml

which will create:

• balancer.toml
• controller.toml
• node.toml
• orchestrator.toml
• cli.toml

Then you can run the EDGELESS-in-a-box, which is a convenience binary that runs every necessary component as one, using the generated configuration files:

target/debug/edgeless_inabox

Congratulations 🎉 now that you have a complete EDGELESS system you may want to check the the examples/ directory, which contains several workflows/functions that are representative of the current EDGELESS features.

You can find here the full list with a short description of each.

Next steps

Please refer to the following specific docs:

• A step-by-step guide to deploying a minimal EDGELESS system
• Repository layout
• How to create a new function (YouTube tutorial)
• How to compose a new workflow (YouTube tutorial)
• Examples shipped with the repository

Contributing

We love the open source community of developers ❤️ and we welcome contributions to EDGELESS.

The contributing guide contains some rules you should adhere to when contributing to this repository.

License

The Repository is licensed under the MIT License. Please refer to LICENSE and CONTRIBUTORS.txt.

Funding

EDGELESS received funding from the European Health and Digital Executive Agency (HADEA) program under Grant Agreement No 101092950.