Placing FaaS applications onto Fog infrastructures is an open problem presenting various challenges. It requires considering hardware and software requirements of single functions as well as Quality of Service requirements of the overall application. In this article, we propose a declarative methodology to address the placement of FaaS applications onto Fog infrastructures, supported by a running prototype. Our methodology considers hardware and software requirements, and latency constraints on functionfunction and function-service interactions. Particular attention is given to information flow security constraints and trust relations among the involved stakeholders, to rank eligible output placements. A lifelike motivating example from augmented reality is used to showcase the prototype.
ifnding the mappings from functions to Fog nodes, requires to consider hardware, software and
QoS requirements of single functions as well as their composition into complex applications,
and requirements on function bindings with external services. As other application placement
problems in the Fog, deciding on the above is NP-hard, thus worst-case exp-time [
Speaking of QoS, FaaS placement requires constraining the function-function and
functionservice latencies, which are crucial to support latency-sensitive applications [
This article builds over our previous work on secure and trust-aware multiservice application
placement in the Fog [
We consider a simple orchestration mechanism where FaaS services are chained together
as sequences of functions. We call it FaaS chains, and they represent a first step towards
placing more complex FaaS orchestrations (e.g. those of OpenWhisk [
Our approach features two desirable properties to support the placement of FaaS in the
Fog. First, it is declarative, hence more concise, easier to understand and maintain compared
with procedural solutions, and it ofers high flexibility and extensibility, to accommodate the
ever-changing needs of Fog scenarios. Second, it is intrinsically explainable as it derives proofs
for input queries by relying on Prolog resolution engines, and it can be easily extended to justify
why a certain placement decision was made, in the spirit of explainable AI [
The rest of this article is organised as follows. After describing a lifelike motivating example from augmented reality (Sect. 2), we illustrate FaaS2Fog methodology (Sect. 3), used to solve 1Open sourced and freely available at: https://github.com/di-unipi-socc/FaaS2Fog. and discuss the motivating example (Sect. 4). After presenting closely related work (Sect. 5), we conclude by pointing to some directions for future work (Sect. 6).
This section illustrates a lifelike motivating example to highlight the challenges related to the FaaS chain placement problem. Consider an Augmented Reality (AR) application trying to avoid people gatherings in commercial areas of a city centre, so to contrast the spreading of Covid-19, by load-balancing people presence across similar shops. When users point with their smartphones the entrance of a shop they are about to enter, the application renders over the video 3D information about the number of people inside and its overall capacity. If a high risk of gathering is detected, the application suggests alternative similar locations to the users by giving them 3D AR directions, along with incentives (e.g. discounts, special ofers) to move away from the gathering area. Such an application is implemented by a FaaS chain (Fig. 1): 1. , which authenticates the user into the service, 2. ℎ , which recognises the shop entrance in the framed images, so to discriminate among physically close activities, 3. , which identifies the shop by its image and coordinates via an external map service, also retrieving all shop information, 4. ℎ , which computes the risk of gathering (based on crowd-sensed information), individuates alternative shops and incentives to move there, 5. , which renders AR information over the framed video footage and sends it back to the mobile client.
For each function in the chain, Fig. 1 lists the software requirements in terms of required runtime support, and the hardware requirements. For instance, function ℎ needs Python3 and NumPy to be available on the deployment node, along with 2 GB of RAM, and 4 vCPUs at 1.5 GHz at least.
UserInfo 13 ms
ShopInfo GSahhotpeIrnIfnof,o 12 ms 12 ms UserInfo, Screenshot, Coordinates, SensorsInfo fLogin [py3] 11GGB RAM 22vCPUs 00..55GGHHzz
Scr1e0enmsshot, FfLSohgoipn Scr1e3emnsshot, fGeo CSoeonrsdoirnsaItnefso, [p2y4G13v.B,5CnGPRuHUAUAmzMszMsPyy]] CCSoreoonrpsdpoierndsaSIthneofspo,, 11020G[[.v.B44jCjGGPRssHHUA]]zMsz 10 ms
2vCPUs 00..55GGHHzz 15 ms
2GB RAMM 4vCPUss 1.2GHz
Each function connects to the type of external service(s) it will need to bind with at runtime (represented as dashed circles). As an example, function needs to bind to an instance of the userDB service. Function-function and function-service interactions (represented as arrows) are annotated with the parameters they exchange and with the maximum end-to-end latency they tolerate between their deployment nodes. For instance, passes to ℎ a Screenshot of the framed shop, with its geographical Coordinates, and SensorsInfo from the client smartphone. Such interaction tolerates a latency of at most 10 ms.
To prevent sensible data from leaking, chain input parameters are labelled with suitable security types, as those in the lattice of Fig. 2, modelling the security level pertaining to certain sensible data from top (i.e. secret) to low (i.e. public).
Those security labels propagate with data along the function chain (and across external services), determining top a security context for each function (and service), based medium on the data it will process. For instance, inputs UserInfo, Screenshot, Coordinates, SensorsInfo can be low labelled by the tuple (top, low, low, low), assigning to Figure 2: Example security lattice. such function the highest type among those, i.e. top. Security types propagate to the outputs (Screenshot, Coordinates, SensorsInfo) with the labels (low, low, low), which will be used in turn to determine the (low) security context of ℎ . Finally, we assume that chain triggers come from event generators – invoking suitable orchestrator API – that are connected to infrastructure nodes. In our example, the event generator is the client application, which we assume to connect to the closest available node. Functions in each chain are executed sequentially, and the final result of the computation is returned to the client application.
Fig. 3 sketches the target (city centre) Fog infrastructure, upon which the chains described
above will be placed and run. Nodes are owned and managed by diferent providers, the
information we need are their software and hardware capabilities, the services they host, and
their security countermeasures, expressed as per the taxonomy of Fig. 4 (as in [
Service Service Service
Id Type Provider myUsers userDB appOp cMaps maps cloudProvider openM maps openS myShop shops. appOp 5 ms switch (univers8i0tym)s
[py3,js] 2GB,2vCPUs,2GHz [pubKeyE]
7 ms 5 ms labServer (university) [py3,js,numPy] 4GB,4vCPUs,2GHz [antiTamp,pubKeyE]
7 ms officeServer (university)
[py3] 1GB,2vCPUs,1GHz [] cloudNode (cloudProvider)
[all] ∞GB,∞[CaPlUls],∞GHz 30 ms ispRouter
(telco) [py3,js,numPy] 4GB,4vCPUs,2GHz [antiTamp,pubKeyE] 7 ms 8 ms southAntenna 12 ms
(telco) [py3,numPy] 2GB,4vCPUs,1.5GHz [pubKeyE] northAntenna (telco) [js] 2GB,2vCPUs,1.5GHz [antiTamp,pubKeyE] 7 ms private2 (privateCitizen2)
[py3] 0.5GB[,p1uvbCKePUyEs,]1GHz 6 ms private1 (privateCitizen1)
[js] 1GB,2vCPUs,2.5GHz []
As an example, node switch, owned by university, supports Python and Javascript code, and features 2 GB of RAM, 2 vCPUs at 2 GHz, and public key encryption as security countermeasure. Services instances are managed by their providers that detail information about service types and deployment nodes. For instance, service cMaps provided by cloudProvider is of type maps and is deployed to node cloudNode. Links between nodes are annotated with their end-to-end latency, e.g. the latency between ispRouter and northAntenna is 8 ms.
Virtualisation
Communication Access Logs Authentication Host IDS Process Isolation Permission Model Resource Usage Monitoring Restore Points User Data Isolation
Certificates Firewall IoT Data Encryption Node Isolation Mechanims Network IDS Public Key Cryptography Wireless Security
FOG SECURITY
Data Backup Encrypted Storage Obfuscated Storage
Physical Access Control Anti-tampering Capabilities
Other Audit
Deploying the chain in Fig. 1 onto infrastructure of Fig. 3 requires satisfying all functions’ software, hardware and latency requirements, and determining a suitable binding from functions to the service instances they need. Furthermore, function labels and node labels should be compatible, i.e. a node can host a function only if it features an equal or higher security label. As an example, the application operator can establish that a node featuring public key encryption without anti-tampering is labelled as medium security. This means that the node can only support functions labelled either low or medium. Note that this is required to avoid leaking data from a higher to a lower security context.
The problem we aim at solving in the above scenario is as follows:
Is there any eligible placement and service binding of chainGath over the available Fog infrastructure, such that all software, hardware, latency, external service, security requirements are met, and data leaks are avoided? Can trust relations among involved stakeholders help in evaluating the quality of eligible placements? In Sect. 4 we will show how our methodology and prototype FaaS2Fog can be used to answer the above questions.
In this section, we describe our methodology to place FaaS chains to Fog infrastructure. We illustrate both the modelling (Sect. 3.1) and the declarative solution (Sect. 3.2) of the problem, showing the main Prolog2 facts where clarifications are needed. 3.1. Modelling Applications, Infrastructures and Trust Declaring FaaS Chains. Application operators declare the requirements of a function F they will chain into FaaS applications using functionReqs(F, SoftwareRequirements, HardwareRequirements, ServiceTypeRequirements). Such requirements include SoftwareRequirements and HardwareRequirements, as well as ServiceTypeRequirements used to bind at run time service instances to be invoked by the function.
The function behaviour of a function F is defined by a relation between security types of input data (Inputs), output data (Outputs) and data exchanged with external services (ServiceInteractions). The declaration of function behaviours is functionBehaviour(F, Inputs, ServiceInteractions, Outputs):- ...
We assume that such information can be defined manually, or obtained by exploiting static
analyses and type systems (see e.g. [
A Function chain FChain managed by Operator is declared as functionChain(FChain, Operator, EventTrigger, Functions, Latencies). where are included the list of Functions forming the chain, the FaaS Operator, the EventTrigger associated with the chain, and the maximum tolerated Latencies from the trigger to the ifrst chain function, and between consecutive chained functions. Chain triggers are denoted by pairs containing the trigger source and the list of security labels of its parameters (e.g. [top,low,low,low]). Those security labels will match the input types of the first function and propagate along the chain according to declared function behaviours. Chained functions are denoted by pairs containing a function identifier and a list of actual service instances each function will bind to. Bindings either specify a certain service instance identifier or are left unbound, meaning that any service of the required type can satisfy the requirement.
Application operators also declare a lattice of the security types to define their functions and function chains, as the one in Fig. 2, using g_lattice_higherThan(Higher, Lower). to represent each ordered pair of the lattice with the Higher and the Lower security types. Declaring Fog Infrastructures. Infrastructure node are declared as node(NodeId, ProvId, SecCaps, SWCaps, HWCaps). including the NodeId (e.g. its IP address) and the security, software and hardware capabilities featured by the node (viz. SecCaps, SWCaps and HWCaps), which enable FaaS2Fog to check the latter against function requirements. Security capabilities are lists of literals from Fig. 4.
End-to-end links between nodes (NId1 and NId2) are associated with the average Latency in milliseconds experienced between the nodes, declared as
2A Prolog program is a finite set of clauses of the form: a :- b1, ... , bn. stating that a holds when b1 ∧ ⋯ ∧ bn holds, where n≥0 and a, b1, ..., bn are atomic literals. Clauses with empty condition are also called facts. Prolog variables begin with upper-case letters, lists are denoted by square brackets, and negation by \+. Conventionally, a Prolog predicate pred with N arguments is indicated as pred/N.
External services, running on available nodes, are declared by service providers as service(ServiceId, ServiceProvider, ServiceType, NodeId). where are specified the ServiceId, the identifier of the ServiceProvider, the ServiceType, and the NodeId of the service host node.
The declaration of an event generator EG is
eventGenerator(EG, EventType, NodeId).
and it includes the EventType of generated triggers it can generate as well as the NodeId of the
node with which it is connected. It is worth noting that data about infrastructure capabilities,
services and event generators can be obtained by exploiting available monitoring tools targeting
Fog settings (e.g. FogMon [
Declaring Security Policies. The security context of nodes and external services is determined
according to the security policies specified by application operators. Node and service labelling
is performed as per the same security types of functions parameters to guarantee that types
can be checked against each other and to enforce that functions are placed onto nodes and
interacts with services that feature at least their security type. Node labelling is specified by
the declaration
assignNodeLabel(Node, SecurityContextLabel) :- ...
meaning that the SecurityContextLabel is assigned to the Node if all conditions of the right
hand-side of the rule hold. For example, a node is labelled top only if such node features both
anti-tampering and public key encryption among its security capabilities. Analogously, external
services are labelled by defining the security policies based on the available service information.
Declaring Trust Opinions. All involved stakeholders (i.e. application operators, infrastructure
providers, service providers) can declare trust opinions towards each other. Following [
Trust relations are checked between the application operator and the node operator where functions are placed. Analogously, trust re- ⟨ , ⟩ ⊗ ⟨ ′, ′⟩ = ⟨ ′, ′⟩ lations are checked between the application ⎧⟨ , ⟩ if > ′ loypienrgatoonr a-nPdroebxltoegr,nFaalasSe2rFvoicgeapnrnoovtiadteersse.aRceh- ⟨ , ⟩ ⊕ ⟨ ′, ′⟩ = ⎩⎨⟨⟨m′a,x{′ ⟩, ′}, ⟩, iiff =′ > ′ output eligible placement with its overall trust assessment computed as described above. Figure 8: Semiring ⊗ and ⊕ operations.
In this section, we solve the motivating example4 of Sect. 2 by answering the questions raised therein. Security policies to label services specify that all the services provided by appOp are labelled top, the maps services provided by cloudProvider are labelled medium, and all the other services are labelled low. We assume that input parameters generated by userDevices triggering the chain are labelled [top,low,low,low], only considering user’s data as sensitive information.
Given these ingredients, we simply query the main predicate of FaaS2Fog, faas2fog(chainGath, Placement), to determine eligible placements for the FaaS chain. FaaS2Fog matches trigger types with the input labels of function (UserInfo, Screenshot, Coordinates, SensorsInfo) and, by propagation, it determines the labelling of functions5 as: ( , top), ( ℎ , low), ( , low), ( ℎ , medium), and ( , medium). Afterwards, eligible placements and service bindings meeting all software, hardware, latency, and security requirements of the chain of Fig. 1 are looked for by the placement phase. Table 1 summarises all obtained results. They are 9 eligible placements 4Full example code at: https://github.com/di-unipi-socc/FaaS2Fog/tree/main/examples/ITASEC21 5Note that, labelling Coordinates as medium, we would obtain a diferent labelling, i.e. ( medium), ( , medium), ( ℎ , medium), and ( , medium). , top), ( ℎ , and bindings – 1 - 9 , one per row – that satisfy all set requirements. Each column in the table corresponds to a chain function and lists the placement node and the service bindings. It is worth mentioning that while service bindings are already specified for myUserDB) and for ℎ (with the service myGatherS), the binding of (with the service was left unbound and is determined by FaaS2Fog so to meet the required low security context. As a consequence, depending also on function-service latency considerations, such requirement is bound either to the openM (e.g. 1 ) or to the cMaps instance (e.g. 2 ).
f Login We now also consider the trust network of Fig. 9, where links are annotated with (Trust, Confidence) values. For instance, appOp has a trust level of 0.99 with confidence telco provider, and a trust level of 0.9 with confidence 0.9 toward the cloudProvider provider.
Table 2 lists the trust and confidence values associated to the found placements 1 – 9 , listed in placement(s), as well as to set a minimum trust level to meet. For instance, blindly choosing the first result 1
of Table 1 actually leads to selecting one of the placements which can be trusted less (viz. (0.27, 0.23)) among the eligible ones. By considering trust assessment, the application operator will instead likely choose 4 , with the best trust level (viz. (0.77, 0.48)).
0.99,0.9 appOp
telco 0.9,0.9 0.9,0.9
0.9,0.9 0.5,0.9 private1 0.6,1 cloudProvider
university 0.8,0.85
0.9,0.9 private2 0.8,0.9
0.8,1 0.89,0.9 openS
P1 P2 P3 P4 P5 P6 P7 P8 P9
Trust (0.27, 0.23) (0.61, 0.31) (0.27, 0.23) (0.77, 0.48) (0.34, 0.35) (0.34, 0.31) (0.17, 0.28) (0.30, 0.28) (0.24, 0.21)
In this section, we survey some closely related work proposing declarative solutions to resource management in Cloud or Fog scenarios and techniques to assist the placement of orchestrated serverless functions in the Fog.
Speaking of declarative approaches to resource management, some have been proposed to
manage Cloud resources (e.g. [
Targeting FaaS architectures, Pinto et al. [
Cicconetti et al. [
Only [
This article introduced a life-like example concerning the problem of determining eligible placements of FaaS chains to Fog infrastructures, that is addressed with a declarative methodology and its prototype, FaaS2Fog. Our approach considers hardware, software and latency requirements, and exploits information-flow security policies as well as infrastructure security capabilities. Eligible placements are ranked by employing semiring-based trust relations among the involved stakeholders. From the architectural viewpoint, FaaS2Fog employs information on the application, on its security types and on infrastructure labelling policies (declared by application operators), data on infrastructure capabilities (collected via distributed monitoring tools, and declared by infrastructure operators), and trust relations (declared by all involved providers).
Our approach shows some qualifying strenghts to address FaaS placement in Fog scenarios.
Its declarative nature makes it easier to define FaaS chain requirements and security policies,
infrastructure capabilities, and trust relations. Moreover, it naturally supports a flexible approach
since it allows the definition of new requirements (e.g. bandwidth, availability of specialised
hardware) or security considerations (e.g. provider whitelisting). Finally, placement explanation
can be obtained by taking advantage of proof paths determined via the -Problog engine.
Thus, employing explainable placements combined with information-flow and trust assessment
can reduce the possibility of leaking critical data to untrusted or insecure parties during the
deployment of FaaS chains. On the other hand, FaaS2Fog does not yet handle structured FaaS
orchestrations, obtained by combining functions with traditional control mechanisms (e.g.
branches, loops). This needs to be addressed to model more complex use cases, also extending
information flow analyses to the general case. Additionally, human-readable explanations on
why a certain placement was (or was not) output would further improve interactions with
the users and their trust in systems based on the proposed methodology. Finally, FaaS2Fog
incurs in worst-case exp-time to determine valid placements. As serverless functions are usually
on-demand and short-lived, it is crucial to assess execution times over larger examples, and to
improve on those via heuristics or continuous reasoning [
In addition to tackling all aforementioned points, in our future work we plan to extend the
methodology underlying FaaS2Fog by formally defining type judgement rules for a
featurecomplete orchestration language, showing how they can be naturally expressed in -Problog.
Last, we intend to implement a service based on FaaS2Fog and on the
Logic-Programming-asa-Service paradigm [
This work has been partly supported by project “Lightweight Self-adaptive Cloud-IoT Monitoring across Fed4FIRE+ Testbed” (LiSCIo) funded by Fed4Fire+ and“Continuous QoS-compliant Management of Software Applications over the Cloud-IoT Continuum ” (CONTWARE) funded by the Conference of Italian University Rectors.