Functions on edge — Part 2

So how does FaaS orchestration works and combine simple well-defined serverless functions into more complex applications. A well defined set of constraints that identifies the need of a careful evaluation of trade-offs in function orchestration is essential . Those trade-offs mainly concern the fact that functions should be considered as black boxes, function orchestration should preserve a substitution principle with respect to synchronous invocation, and function invocations should not be double-billed. For example the considered reactive core of OpenWhisk (presented in part 1) is based on events (triggers) which represent a class of topics in an abstract message queue. Functions (Actions), have a unique name, their specific source codes, and always input and output dictionaries. A serverless orchestration is then represented as a set of rules, associating a specific topic of a trigger to a function. Each rule has an enabled status bit that determines if a message of a trigger results in an invocation of the function. The two operations to compose functions are invoke, used to run a function on a given input, and fire, used to create a new message for the event queue related to a trigger. When a new message is created, all the rules associated with that trigger are checked, and the enabled rules start the function invocations with the message as input. This mechanism is completely asynchronous and only permits composing sequences of functions based on events. To enable programmers with correctness of the serverless functions and FaaS orchestrations they implement, helping them in better understanding and dealing with low-level operational details of FaaS platforms SPL. SPL is a domain-specific language based on a operational semantics, that models a serverless platform accounting failures, concurrency, function restarts, and instance reuse happening under the hood of such platform and considering interactions with external services. Communication is via message passing, modelling events via the “receive event” and “return result” primitives. Overall, the SPL language for function orchestration features the followings : simple function invocation, sequential execution of functions passing the output of one to another, and application of a function to a tuple modifying only the first element of the tuple while leaving the others unchanged. They permit expressing only simple orchestrations of serverless functions, without loops nor conditionals, which, however, have been implemented in the experimental prototype of SPL. Last, to make the input/output format uniform, a sub-language for JSON transformations is used. Serverless Kernel Calculus (SKC), a formalism to model event-based function orchestration which combines features to describe functions and their communication, respectively. The basic model is then extended with stateful computation relying on message queues or databases, and event-based function compositions. Features typical are used to model (recursive) function declarations, while communication is based on futures that represent the return value asynchronous function invocations. The event-based programming paradigm, typical of FaaS systems, is then modelled by encapsulating events in user-defined handler functions, which cannot directly invoke one another. Last but not, least, external services are considered as potential sources of events triggering function executions. An evaluation of the expressiveness of SKC in capturing all relevant features of FaaS orchestrations is performed over a real use case from a user registration system implemented in AWS Lambda. Exploit the definition of FaaS orchestration expressed as workflows to model FaaS applications or to perform evaluations on cost or performance is propose by Triggerflow, an architecture for serverless workflows. Such a proposal aims at supporting heterogeneous workflows while exploiting both the reactive design of the serverless paradigm and good performance for high-volume workloads. The architecture of Triggerflow is based on an Event-Condition-Action model in which triggers (active rules) define which function (i.e. action) must be launched in response to Events, or to Conditions evaluated over one or more Events. In such a model, workflows are represented as a finite state machine, where the states are serverless functions and the transitions are labelled by triggers. The set of initial states are functions linked to initial events, the set of final states are functions linked to termination events.

A trigger is a composed by an event, the atomic piece of information that drives flows in applications, a context, the state of the trigger during its lifetime, a condition, the active rules that filters events to decide if they match in order to launch the corresponding functions, and an action, one or more function launched in response to matching conditions. Experimental assessments are performed using AWS Lambda and IBM Cloud Functions showing that Triggerflow can support high-volume event processing workloads and transparently optimise workflows of scientific applications. Combine learning techniques is used to predict function execution times and output parameters distributions and simulations to predict costs in order to compare and optimise the cost of executing FaaS orchestration workflows. Workflows can be declared by specifying the business logic of each function, the data storage or transfer backends it needs, and its target execution tier (IoT, Edge or Cloud). Performance evaluation is prototyped in OpenFaaS and it is based on metrics measured both at the function level (e.g. runtime latency, storage read/write latency, and the function communication latency) and at the workflow-level (e.g. CPU usage, network throughput). A benchmark is proposed for two representative applications (i.e. video analytics and IoT-hub management). From a different perspective, Anzer, is a domain-specific language that enables type-checking on function compositions. Anzer enables explicit and type-safe FaaS compositions by relying upon a type system that features basic types (integers, strings, boolean) along with the possibility to include user-defined types. A Maybe constructor is also featured by the language to allow for optional data types and polymorphism is supported, based on a well-defined notion of sub-typing. Type checking is performed on the description of the input function compositions, and compositions are considered safe if and only function inputs and outputs are coherently described. Besides, Anzer offers a mechanism to recognise failed computations based on monads, while it does not account for the presence of external services nor for events generated externally from the function compositions. The current prototype release of the Anzer platform is still under testing, relies upon Apache OpenWhisk and only supports the Go language. Finally, focus on MEC settings, the approach extends an actor-based framework in a serverless manner, where actors can be written as serverless functions. The Python-based declarative language CalvinScript is used to implement IoT applications capable of expressing (also through a graphical representation) the data-flow between functions and the placement of functions on specific nodes. The control flow of an application is handled by writing specific functions that handle the flow, e.g. to express a conditional branch a function is needed that receives input data, tests a condition and passes the data to another function based on such test.

TBC…