Function-as-a-service is an event-driven compute paradigm that allows to execute primarily stateless, and arbitrary code in heterogeneous cloud computing platforms[1][2][3]. PHYSICS is a research project that seeks to enhance this simple FaaS model, some of the architecture principles of the PHYSICS platform are described as follows:
- It follows the FaaS model – the basic building blocks of the PHYSICS platform are the functions.
- The way to trigger actions are by using orchestrated flows – the PHYSICS platform supports creating flows (using a GUI) in order to ease application development. These flows are orchestrated by flow orchestration tools such as NodeRED or OpenWhisk.
It makes usage of the compute continuum – another important aspect of the PHYSICS platform is the ability to deploy functions where they can be executed most efficiently, anywhere in the compute continuum, from the data center to the edge.
So let’s look at the following simple flow:
The query data step process some complex query on a database in the data center. Based on the query result, there is a request sent in parallel to multiple edges to fetch information from the edge sensors. These results are inputs to an additional step that is also executed in the data center.
In a high-level view of the FaaS model, this looks relatively simple – a function can run everywhere, and as long as there exists an endpoint, it is possible to call each function from any location in the network.
Based on the simple function as a service model described in the previous flow, there are novel challenges imposed by the infrastructure architectural topology of the EDGE. These challenges are:
- Keeping a streamlined workflow execution across multiple Kubernetes clusters.
- The workflow execution must include soft-handover tasks, so forth, parts of the workflow are executed depending on the criteria defined by the workflow controller.
- The workflow execution must ensure that the authentication, authorization, and accounting of any action is enforced across the continuum.
- The network connectivity across the continuum must be established.
- Keeping potentially disconnected locations stable enough to run the workflows.
- Provide mechanisms to recover from connection issues in the edge without affecting the workflow execution.
- Provide a method to support and handle edge locations where there might be low bandwidth.
And all the above aspects should be handled transparently, without any involvement of the flow designer, since the platform decides where to deploy each function.
These are some of the challenges that we encounter in the PHYSICS project, and we work on solving them by the platform, in a transparent manner to the flow creators.
References:
[1]: Architectural Implications of Function-as-a-Service Computing, https://doi.org/10.1145/3352460.3358296
[2]: Cloudburst: stateful functions-as-a-service, https://doi.org/10.14778/3407790.3407836
[3]: FaaSter: Accelerated Functions-as-a-Service with Heterogeneous GPUs, https://doi.org/10.1109/HiPC53243.2021.00057
It is, per se, cost-saving as well as an accelerator of time-to-market as it supports the creation of a key differentiation factor for any kind of product.
Focusing only on EU projects, one of their main handicaps is to get out of the research bubble, identifying topics not yet addressed and real-world user needs far beyond the consortium expectations. This will help to better eliminate the boundaries between business and research activities in collaborative environments, reducing risks and better using funds while focusing on results with a wider end user scope. There are several types of innovation according to its inclusion level (intercompany, intracompany, for experts, publicly open), and the purpose of use (marketing, gathering insight, finding talent, R&D). PHYSICS follows an open innovation strategy for maximising its adoption impact, providing tailored messages and offerings according to users’ needs, and not only from the consortium perspectives. Furthermore, it is open to different external stakeholders, with or without a technical background, that can provide valuable feedback about current technical challenges and market gaps while validating the proposed project results and exploitation strategy. With the main goal of attracting and engaging external stakeholders by involving them in the project R&D processes, aiming to maximise impact and foster the adoption of results.
Stay tuned, as everything will be documented in the PHYSICS Handbook, including a replicability plan.
[1] Viima, Open Innovation, https://www.viima.com/blog/open-innovation
