Beyond Cloud: Serverless Functions in the Compute Continuum

The popularity of serverless computing, and Function-as-a-Service (FaaS) in particular, has been constantly growing for years. These novel paradigms emerged as an evolution of traditional cloud computing services [1], with the aim of relieving users from all the burden of resource allocation and management. Specifically, FaaS allows users to deploy loosely-coupled code units (i.e., functions), and execute them on-demand in a scalable way. In the meanwhile, FaaS providers take care of all the operational issues, including the creation of ephemeral sandboxes (e.g., usually software containers) where users’ functions are executed. Compared to traditional virtual machine (VM)- or container-based services, no resources must be provisioned upfront to face incoming workloads, enabling cost savings. Furthermore, as thousands of parallel function instances can be spawned to serve incoming bursts, FaaS also promises increased scalability.

FaaS emerged as an evolution of traditional cloud offerings, and nowadays all the major cloud providers offer FaaS products (e.g., AWS Lambda, Azure Functions, Google Cloud Functions). Besides them, various open-source frameworks have also appeared (e.g., Apache OpenWhisk, OpenFaaS, Knative, nuclio), allowing users to run FaaS systems on-premises. In recent years, we have witnessed a surge of interest for running FaaS applications at the edge of the network as well [2, 3] including commercial products (e.g., AWS Lambda@Edge, Azure IoT Edge, Cloudflare Workers), as well as in the emerging compute continuum [4, 5]. For instance, applications in the domain of industrial Internet-of-Things (IoT), smart cities, or augmented/virtual reality, which usually require possibly massive inputs to be processed with very low latency, can hardly have their requirements satisfied by transferring data to remote cloud data centers and back. Moreover, the diffusion of emerging application paradigms, such as edge intelligence, also requires the flexibility to deal with both short-running model inference to long-running and data-intensive model training. As such, the compute continuum (or, edge-to-cloud continuum), that combines centralized cloud data centers with heterogeneous and decentralized fog/edge computing resources [6], represents a natural deployment solution for these applications, blending together near-user computation and the possibility to leverage the cloud resources’ richness, scalability, and reliability. Furthermore, such a rich computing landscape also enables trade-offs between performance, operational costs and energy consumption [7], as different deployment options can be selected and possibly adapted at run-time.

However, the FaaS paradigm has way more limited support in the continuum compared to cloud-like environments, both because of limitations of the existing frameworks as well as intrinsic complexities of the execution environments at the edge of the network. Specifically, most of the existing frameworks show centralized architectures, which do not suit geo-distributed environments well. In particular, scheduling functionalities are often centralized, making it difficult to exploit the variety of distributed computing resources available in the continuum. Moreover, the reduced resource availability, the increased heterogeneity in terms of hardware resources, as well as the security concerns, that characterize edge/fog environments pose new or more severe challenges to FaaS platforms.

The research community has started investigating solutions to better support FaaS out of the traditional and over-provisioned cloud or cluster environments, through, e.g., novel frameworks, or strategies to better schedule invocation requests over distributed FaaS systems, reducing energy footprint and increasing security. Nonetheless, the problem of deploying and running serverless functions in the continuum as a whole is far from being solved. In this paper, we review the key challenges impacting FaaS in the compute continuum and the solutions presented so far in the literature to overcome them. We mainly follow an architectural approach, analyzing first the FaaS systems in the continuum, then the issues to be addressed for the efficient resource and function management, and finally the applications that can mainly benefit from the deployment in the new environment. Based on our analysis, we identify the current research trends as well as the open issues that still require attention from the research community and outline possible research opportunities for further investigations in this field. Our goal is not to provide a systematic review of the state of the art, but rather help researchers understand the major challenges and trends in the field, which could inspire and motivate new investigations.

The rest of this paper is organized as follow. In Sect. Related and Complementary Work, we briefly review related surveys and papers. In Sect. Background, we introduce background concepts about FaaS and the continuum. We give an overview of our discussion of the key issues FaaS adopters face in this novel environment in Sect. Overview, diving into specific aspects in the following Sects. System Frameworks and Infrastructures–Applications. We discuss open issues and draw conclusions in Sect. Open Issues and Future Research Directions.

The technical and scientific advancements related to the adoption of serverless computing in the compute continuum have been already discussed in a few recent works. The publications closest to this one are [4] and [2]. The former, authored by our research group, provides a brief discussion of the challenges and potential benefits associated with serverless adoption beyond cloud data centers. Compared to [4], we provide here a broader and deeper discussion of the topic, specifically as regards strategies for stateful functions, workflow management, and sustainability aspects. Raith et al. [2] review and evaluate the maturity of serverless approaches for the edge-to-cloud continuum, considering both commercial and open-source frameworks and platforms. With respect to their work, we provide a more in-depth analysis of the research challenges and efforts towards the adoption of FaaS in the compute continuum with a focus on system resource and FaaS management and considering also sustainability, privacy and security as key dimensions.

Two systematic literature reviews have been published on this theme as well, and can complement our study. The challenges posed by FaaS in the continuum are reviewed in [5] through a systematic mapping study, where the main issues associated with infrastructure and frameworks are discussed. Cassel et al. [8] recently presented a systematic literature review on the adoption of serverless computing in IoT scenarios. While not explicitly focused on the continuum, many of the challenges discussed in [8] overlap with those faced in the scenario we explore in the following.

Differently from this work and the other ones mentioned above, Xie et al. [3] discuss open challenges for serverless computing at the edge of the network from the perspective of networking. Their discussion includes, e.g., issues such as network architecture design, the choice of suitable communication protocols, service lifecycle management and discovery.

More general reviews of serverless computing, primarily focused on cloud-like scenarios, are, e.g., [9,10,11,12]. Li et al. [9] review the design space underpinning serverless computing systems, at different layers (i.e., virtualization, encapsule, system orchestration, and system coordination). Shafiei et al. [10] instead discuss the development of serverless computing with emphasis on application domains, identifying challenges and opportunities for the adoption of this paradigm. Conversely, Mampage et al. [11] look at system-level issues, reviewing and discussing the challenges related to resource management in serverless computing systems. Leitner et al. [12] present a mixed-method study, combining interviews with practitioners involved in FaaS development, a systematic analysis of grey literature, and a web-based survey, to analyze the advancements and issues in serverless adoption.

Function-as-a-Service

FaaS systems allow their users to execute units of code (i.e., functions) in a serverless fashion. Functions are loosely coupled, modular application units, which can be defined using a variety of programming languages. Functions are executed on-demand upon invocation by clients, or automatically in response to pre-defined events. Importantly, no computational resources are reserved upfront, and they are allocated only when functions must be executed. This marks an important difference with traditional Infrastructure/Platform-as-a-Service scenarios, where resources are reserved (and likely billed!) even if they remain idle. Moreover, FaaS providers take care of most of the operational issues associated with function execution (e.g., spawning execution environments, auto-scaling), which – in traditional cloud services – fall mostly under users’ responsibility.

FaaS providers accommodate function invocation requests by concurrently serving them within the same shared computing infrastructure. As such, to guarantee isolation of concurrent workloads, possibly belonging to different users, functions are executed within sandboxed execution environments like software containers or microVMs, which allow providers to rapidly provision resources upfront to face incoming requests. With no loss of generality, in the rest of this section we assume the runtime environments to be containers, as for most existing FaaS frameworks.

Containers are created by the FaaS system as needed, and initialized with the code and libraries needed for the function to be executed. In principle, upon arrival of an invocation request, a new container is created and added to the pool of active containers. In this case, the incoming request has to wait for the container to be fully initialized before being served and it is said to experience a cold start, which introduces additional delay, typically in the order of hundreds of milliseconds or even seconds. To limit the occurrence of cold starts, upon the termination of a function, idle containers are marked as warm and kept in the container pool, rather than being destroyed. When a new request for the function arrives, if a warm container is available, it is reused to accelerate request serving. Idle warm containers usually stay in the pool for a maximum time (e.g., about 10–15 min in commercial Cloud FaaS offerings) or until their resources must be reclaimed. The interested reader can refer to [13] for a recent survey on the approaches to reduce cold starts.

High-level illustration of the edge-to-cloud continuum infrastructure, and an example application deployment. (Figure from [6])

Full size image

FaaS first emerged as part of public cloud offerings, with services like AWS Lambda, which was announced in late 2014, later followed by Google Cloud Functions and Azure Functions. In this context, FaaS promises seamless scalability, as cloud providers can quickly scale up to thousands of function instances to handle load peaks; simplified application maintenance, as users are relieved from operational issues; and flexible pricing, as users are only charged for the exact amount of computational resources actually used for function execution. The fine-grained pay-as-you-go cost model of FaaS is particularly attractive for applications characterized by intermittent workloads, where costs can be effectively eliminated when functions are idle. Cloud providers are also now offering serverless at the edge by services such as Akamai EdgeWorkers, AWS Lambda@Edge, Azure IoT Edge, Cloudflare Workers, and Fastly Compute, which allow running serverless functions at edge locations managed by the cloud provider.

As FaaS gained popularity, open-source projects have emerged allowing users to deploy and run FaaS systems on their own infrastructures (e.g., Apache OpenWhisk, OpenFaaS, Knative, Nuclio). These frameworks often comprise a few centralized gateway/scheduling components, whereas actual function execution is delegated to a pool of distributed worker nodes.

Compute Continuum

With the widespread adoption and success of cloud computing in the last decades, the need of trading off resource richness of cloud data centers with low latency of network edges stimulated researchers and practitioners to envision new computing landscapes, which soon led to diffusion of edge and fog computing. The consequent emergence of multiple, distributed pools of computing resources, ranging from smart home devices and edge servers to traditional cloud servers, further called for unifying architectures, protocols, and models to allow applications to benefit from the whole spectrum of available resources. In 2018 the idea of a continuity of computational resources, referred to as cloud-to-things, e.g., [14], IoT-fog-cloud, e.g., [15], or IoT-edge-cloud, e.g., [16], continuum, emerged.

The compute continuum, as illustrated in Fig. 1, refers to an architecture where computing, storage, management, and networking functions are distributed along a continuum of computational resources [6, 17, 18]. Accordingly, compared to fog computing, the continuum drops any strong segregation of resources into tiers (e.g., IoT, edge, cloud). The resulting continuum infrastructure includes heterogeneous computing, storage, and networking resources, which are usually geographically distributed and, thus, likely characterized by non-negligible communication delays. Moreover, the infrastructure exhibits dynamic working conditions, influenced by multiple variability sources, including, e.g., mobility of devices, presence of multiple tenants and resource owners. All these aspects significantly increase the uncertainty of the execution environment and thus pose non-trivial challenges for effective application deployment and management, while also enabling potential optimizations in terms of energy consumption, latency, data privacy, and security.

In the remainder of the paper, we review and discuss the main challenges faced by FaaS systems in the continuum and the corresponding solutions (if any). To organize our discussion, we mainly follow an architectural approach, moving from lower-level systems and infrastructures towards applications. Figure 2 provides a visual overview of our review.

Organization of our review

Full size image

Specifically, we first analyze the system-level issues, especially as regards the availability of FaaS frameworks specifically designed for the Continuum and the heterogeneous computing infrastructures that characterize this novel environment (Sect. System Frameworks and Infrastructures). Then, we focus on the issues to be addressed for the efficient resource and function management, covering various aspects, from scheduling to state management and sustainability concerns (Sect. Resource and Function Management). Finally, we review some relevant classes of applications that can benefit from both FaaS and the continuum (Sect. Applications).

Compared to cloud and cloud-like computing environments, where FaaS originally gained traction, the continuum poses various challenges, that span from to the geographical distribution and communication delays, to the resource heterogeneity that FaaS system designers must take into account. We start our analysis in this section by considering how these challenges have been tackled so far, in terms of novel design decisions, especially as regards system architectures and frameworks, and the use of heterogeneous computing resources.

Frameworks

As mentioned in Sect. Function-as-a-Service, several open-source FaaS frameworks have appeared over the years, including, e.g., OpenWhisk, OpenFaaS, Knative, nuclio. Their architecture has been designed having in mind cloud-centric and clustered computing environments and thus does not suit well geographically distributed environments. Indeed, while serverless functions are executed by distributed worker nodes, their system architecture includes centralized scheduling and management components (e.g., the Controller in OpenWhisk, the Gateway in OpenFaaS).

In the last few years, FaaS frameworks specifically designed for use at the edge of the network and possibly in the continuum have been developed. Two main directions have been pursued so far to overcome the limitations of state-of-the-art FaaS frameworks for the cloud:

1. (i)

    Using lightweight mechanisms for function execution and isolation rather than containers, to reduce initialization times and memory footprint;

2. (ii)

    Adopting decentralized architectures, to avoid the performance bottlenecks and single points of failure that often appear in existing frameworks (e.g., centralized schedulers).

The first research direction mainly exploits WebAssembly^{Footnote 1} (Wasm) as a function execution environment. It is a portable, binary instruction format for memory-safe, sandboxed execution, initially proposed for use within web browsers. It has later emerged as a lightweight and highly promising alternative for supporting applications in the continuum [19] as well as serverless functions at the edge [20]. FaaS developers can write functions in a variety of languages, compile them to Wasm binaries, and execute them in a Wasm runtime (e.g., WasmEdge^{Footnote 2}). Wasm’s advantages, including fast start up times (which are well evident for short running functions), compact format, and language support, make it a good fit for FaaS [20]. However, obstacles such as the practicality of Wasm offered by runtimes, the limited support for networking and multi-threading, the lack of support for stateful functions and function orchestrations, make it so far exploited only by research prototypes and slow down its adoption in popular FaaS frameworks.

Unikernels have been recently investigated as another lightweight virtualization technique for executing code in a sandboxed environment at the edge, e.g., [21, 22]. Unikernels combine application code and limited operating system primitives into a specialized, single-address-space machine image. They provide the isolation principles of virtual machines without the overheads of a full virtualization stack, as unikernels boot fast and have small resource footprint and attack surface. However, an evaluation with complex serverless benchmarks still lacks to fully motivate their adoption in the context of edge serverless.

The second research direction relies on the exploitation of decentralized system architectures, with the goal to distribute the decision-making components in charge of request admission, scheduling, and resource provisioning tasks. Among the frameworks specifically designed for the continuum, we identify Serverledge [23, 24], Colony [25], TEMPOS [26], and GeoFaaS [27]. Serverledge [23, 24] is a FaaS framework characterized by a decentralized and modular architecture, where each node is able to schedule and execute functions without necessary interaction with centralized components. To cope with resource overload and guarantee performance requirements, both vertical (i.e., from edge to cloud) and horizontal (i.e., among edge nodes) computation offloading are supported by Serverledge, allowing nodes at lower levels of the infrastructure to virtually extend their processing capacity when needed by forwarding incoming invocation requests that cannot be served locally. In addition, Serverledge supports live migration, to allow nodes to transfer the execution of a function to another node after the function has started. Colony [25] is specifically designed for parallel processing workloads, deployed as serverless functions, in the edge-cloud continuum. Colony enables nodes to process data using their resources while sharing computing capacity across the infrastructure. Unlike most existing FaaS frameworks, Colony automatically converts complex user-defined functions into task-based workflows, utilizing task-based programming models via COMPSs [28]. These workflows are then executed across the infrastructure, with tasks potentially offloaded both horizontally and vertically. Garbugli et al. [26] introduce TEMPOS, an integrated platform designed to manage serverless functions with distinct QoS guarantees across the compute continuum. The platform leverages multiple system-level mechanisms to enforce QoS, including Linux real-time scheduling, prioritized messaging through differentiated message-oriented middleware, and time-sensitive networking. GeoFaas [27] is an edge-to-cloud FaaS platform with a modular and decentralized architecture. It leverages client location information in order to route each request to the nearest available FaaS node and supports vertical offloading when edge nodes are overloaded. To the best of our knowledge, only Serverledge and GeoFaas source codes have been publicly released.

Another relevant system is funcX [29], a distributed FaaS framework designed for scalable, high-performance remote function execution. It separates cloud-based management tasks from function execution hosted at the edge, supporting multiple runtime environments. However, funcX centralizes its management and scheduling responsibilities in the cloud. Similarly, FunLess [30], a FaaS platform tailored for private edge-cloud systems, also centralizes these responsibilities, utilizing a master/worker system architecture with a centralized controller. While both frameworks share centralized management, they differ in their optimizations: funcX is tailored for high performance and scalability in distributed environments, whereas FunLess is optimized for efficient execution on memory-constrained or low-powered edge devices using WebAssembly. This difference reflects their respective use cases, with funcX suited for high-demand scenarios and FunLess designed for resource-limited devices. However, their centralized control may limit effectiveness in geographically distributed settings, where decentralized management might offer better scalability and resilience.

Various frameworks have been studied to address the limitations of major cloud-based systems, while not specifically targeting the compute continuum. One notable framework is Faasm [31], an open-source prototype that introduced faaslets, a lightweight isolation abstraction for high-performance serverless computing. Faaslets are isolated runtime environments based on WebAssembly, which isolates memory of different functions using software-fault isolation, while allowing for shared memory regions for inter-function communication. Faasm also supports local horizontal offloading of invocation requests among worker nodes, but it does not account for geographical distribution.

Sledge [32, 33] and tinyFaaS [34] are additional FaaS frameworks designed specifically for Edge environments. However, differently from the other systems mentioned above, they are currently limited to single-node deployments at the edge of the network. Therefore, their adoptability in the continuum is limited. It is worth noting that Sledge relies on WebAssembly-based sandboxing, and has been extended to support function composition [33].

Table 1 compares the aforementioned frameworks along multiple dimensions, such as system distribution, decentralized scheduling, support for function offloading and migration, function composition, and the type of isolated runtimes used for execution.

We observe that the two research directions for frameworks mentioned above (i.e., lightweight mechanisms for function execution and decentralized architecture) are not orthogonal, that is they can be jointly exploited within the same serverless framework. However, this opportunity has been overlooked so far. We were able to find only a related work represented by the Internet Computer [35], which provides decentralized blockchain-based stateful serverless computation over globally distributed servers by running function code compiled to WebAssembly.

Heterogeneous Infrastructures

Resource heterogeneity is one of the characterizing features of the compute continuum. Necessarily, serverless systems and applications should be able to take advantage of such heterogeneity in order to be successfully adopted in this environment. Heterogeneity can be observed at different levels. First, FaaS nodes are more likely to provide heterogeneous processing capacities (e.g., in terms of memory and/or CPU equipments) at the edge of the network, compared to cloud environments. This form of heterogeneity requires additional care when making scheduling decisions, as further discussed in Sect. Scheduling and Offloading, to make sure that the available resources are used efficiently at all times.

Moreover, in the continuum, available FaaS nodes are increasingly likely to be equipped with heterogeneous hardware, in terms of both different processor architectures (e.g., ARM being the norm rather than the exception at the edge of the network) and availability of hardware accelerators, like GPUs and FPGAs. The existence of heterogeneous processor architectures is both a challenge for function development, who must ensure that applications correctly execute across different nodes, and performance management (see, e.g., [36, 37]).

As regards the support for hardware accelerators, the integration of FPGAs and serverless computing is attracting interest (e.g., [38,39,40]), but we are still in a very early phase of exploration. Conversely, the ability of offloading computation to GPUs has been recognized as essential for serverless functions implementing ML inference (or, more rarely, training) tasks and, thus, has been the subject of various research works (e.g., [41,42,43,44,45]). In this scenario, a fundamental issue regards mechanisms and policies to efficiently share GPU resources among multiple running functions (see, e.g., [45]).

A critical aspect for FaaS systems in the continuum resides in how the available, distributed computing resources are employed for deployment and execution. We discuss these issues in this section, with particular attention on how function execution is scheduled and possibly offloaded (Sect. Scheduling and Offloading), how the function state can be managed (Sect. State Management) and functions composed together in a workflow (Sect. Workflow Management). We also consider two emerging and relevant dimensions for non-functional requirements in a highly distributed setting as the compute continuum is, that is sustainability issues (Sect. Sustainability) and security and privacy concerns (Sect. Security and Privacy).

Scheduling and Offloading

Given the variety of computational resources available in the continuum, a fundamental choice is where (and possibly when) invoked functions should be executed. The solutions proposed in the literature differ with respect to the considered objectives and the adopted methodologies. The first primarily include the minimization of response times and less frequently the reduction of execution costs and energy consumption (as later analyzed in Sect. Sustainability); the latter range from the formulation of optimization problems to heuristics to reinforcement learning (RL) techniques.

Several schedulers share a common objective of reducing response times by strategically distributing workloads across cloud and edge resources. Specifically, many approaches focus on optimizing function placement (i.e., deciding which node should execute each function instance), yet they apply different techniques to achieve these goals. For instance, Schedulix [46] employs a greedy algorithm to sequence and place functions within a hybrid cloud environment, optimizing load distribution and execution time. Deng et al. [47] use a proactive approach to dynamically distribute traffic between edge nodes, identifying the optimal edge server and execution start time for each function. In addition to these, model-driven approaches designed to optimize resource management (e.g., [45, 48, 49]) have proposed solutions to address resource provisioning and allocation in these environments for optimal function placement. In particular, NEPTUNE [45] utilizes Mixed Integer Linear Programming (MILP) to strategically place latency-sensitive functions on edge nodes, factoring in user proximity and GPU availability to accelerate execution. LaSS [48], on the other hand, leverages queuing theory to determine optimal function placement and resource auto-scaling in response to workload changes.

Approaches to resource allocation and scheduling also vary significantly in terms of scale and management style. Ascigil et al. [49] explore both centralized and decentralized optimization methods, focusing on scenarios with statically provisioned containers. FEARLESS [50] leverages a vertical federated RL approach to manage, in a decentralized fashion, function invocation requests within serverless swarms. Filinis et al. [51] present an intent-driven orchestration strategy for serverless computing applications across edge and cloud infrastructures. Their strategy includes two key components: an RL-based autoscaler, that optimizes resource utilization during function deployment, and a scheduling optimizer, that enhances the placement of function chains within the continuum by solving a MILP problem. Risco et al. [52] propose a job rescheduling system that specifically target the edge-to-cloud continuum, aimed at alleviating workload overload by utilizing additional computing resources. Their solution extends the OSCAR serverless platform [53], enabling job delegation to both on-premises clusters and public cloud FaaS services. The results highlight the benefits of leveraging different layers of the continuum to handle unpredictable workloads effectively, as relying solely on edge devices may limit processing speed.

The approaches mentioned above aim to optimally schedule invocation requests to FaaS nodes. Some studies focus instead on function offloading, where a FaaS node, after receiving an invocation request, decides to forward it to another node instead of processing it locally. Offloading can be either vertical (i.e., towards higher layers in the infrastructure, where more capacity is expected), or horizontal (i.e., towards neighboring nodes). Frameworks like Colony and Serverledge support both horizontal and vertical offloading, allowing functions to be executed on peer nodes or cloud resources based on current workloads. This flexibility in function execution is vital for optimizing resource use across the continuum. While major open-source FaaS frameworks like OpenWhisk and OpenFaaS lack native offloading capabilities, researchers have developed federated systems on top of them to enable offloading. For example, DFaaS [54] enables horizontal offloading within a network of OpenFaaS nodes, effectively balancing load across the edge network. A similar strategy is also employed by Cicconetti et al. [55] through an IP-inspired offloading algorithm, and in P2PFaas [56], where the authors proposed a platform for load balancing and scheduling in a peer-to-peer FaaS system.

Vertical offloading is a fundamental mechanism as it enables trading off reduced latency of lower infrastructure layers with increased computational capacity of higher layers (up to the cloud). For example, Das et al. [57] propose a policy for serverless pipelines; they allow users to specify latency and cost requirements for their pipelines, and automatically determine which functions of the pipeline should be executed at the edge or offloaded to the cloud. Similarly, Yao et al. [58] apply deep reinforcement learning (DRL) to minimize long-term latency costs by offloading functions from IoT devices to edge nodes, showcasing the potential of AI-driven approaches in optimizing serverless operations. A game-theoretic approach is explored in [59], examining how wireless devices and a FaaS Edge operator interact to reserve resources for latency-sensitive applications. AuctionWhisk [60], an auction-inspired approach integrated with OpenWhisk, uses vertical offloading in a fog computing scenario, allowing FaaS nodes to locally decide which functions to execute and which to offload to maximize revenue.

Russo Russo et al. [61] present an approach to devise offloading policies in the edge-to-cloud continuum in presence of multiple classes of users, with different performance requirements. Their solution relies on a node-local randomized heuristic, whose parameters are periodically updated through an efficient linear programming problem. Another interesting approach is presented by UnFaaSener [62], which explores offloading function execution from serverless platforms like Google Cloud Functions to traditional VMs. This method exploits underutilized servers within users’ infrastructure, offering a novel way to manage resource allocation and improve efficiency.

We observe that in our analysis we do not explicitly consider serverless auto-scaling as a further dimension of investigation because, to the best of our knowledge, its study for FaaS systems in the compute continuum has been so far neglected. Differently from cloud-based systems, in which scaling up/out indefinitely is possible, resource-constrained edge nodes require to devise new strategies, that also takes into account resource heterogeneity, e.g., as proposed in [63] in the different context of stream processing applications.

State Management

Serverless functions have been traditionally intended as stateless entities, which take some inputs, execute a (possibly complex) piece of code, and return a result. The stateless nature of functions is crucial as it allows the serverless platform to quickly scale the number of instances for each function, without worrying about state integrity, fault tolerance, and consistency. However, it is clear than many functions cannot be purely stateless but require the support of stateful capabilities. In particular, statefulness is useful for data-intensive applications, such as machine learning, robotics, and video processing.

The easiest and most common solution adopted so far to address this issue is to rely on an externally managed state, where functions access application state through external databases or storage services (e.g., key-value (KV) data stores, object storage systems). The downside of this approach is the performance overhead it can induce, as the data access latency can be significant.

While the problem of handling stateful functions has already emerged for cloud-based FaaS, it becomes even more evident in the continuum. In this new environment, relying on external data stores is more challenging, because of the increased latency to access data in centralized (typically cloud-based) storage systems, or the complexity of decentralized storage solutions.

Researchers have studied various solutions to improve the support for stateful FaaS, although most of the effort has been devoted so far to cloud-based systems. A research line focused on integrating storage/caching capabilities in the FaaS framework itself. For instance, Faasm [31] includes mechanisms that allow pipelines of functions to store intermediate data in shared memory regions, for efficient communication. Cloudburst [64], relying on the distributed KV data store Anna, integrates a state caching solution to enable fast data access.

In the continuum, state information can be distributed across both edge and cloud nodes to enhance data locality. Therefore, it is important to carefully decide where to place data and where to execute functions so as to reduce data access overheads. This trade-off is explored, e.g., in [65], where policies to place data and functions are proposed, so as to guarantee desired service levels. A few works propose novel middleware to improve data access performance for serverless functions. For instance, StructMesh [66] is a storage system for serverless in the continuum, featuring a processing plane that manages compositions of functions and a data plane that aggregates the available storage resources in a given infrastructure. Similarly, Sabbioni et al. [67] present the Serverless Persistence Support service, which is a distributed and scalable service implementing an adaptation layer able to improve data access performance for serverless functions. However, this solution does not specifically target edge-cloud systems.

Various works study how to improve data access locality by explicitly taking into account data dependencies. For instance, Lambdata [68] makes the intent of a function input and output explicit for improved locality, e.g., by running functions that read same data on the same worker. Similarly, FaDO [69] defines a special HTTP header to specify the required data bucket in function invocation requests, so that functions are allocated on the requested bucket, if possible.

State in this context often refers also to intermediate/ephemeral data exchanged by serverless function composed into more complex applications. Different approaches have been considered, including the use of remote storage (e.g., [70, 71]), strategies for exploiting data locality (e.g., [64, 68, 72,73,74,75]), and direct function-to-function communication (e.g., [74]). The different strategies for data passing are also compared and evaluated by Cicconetti et al. [76, 77], who consider various approaches, including client-, cloud- and edge-based approaches.

Workflow Management

Single serverless functions rarely implement the business logic of whole applications, but rather multiple functions are often composed into more complex workflows and concur at delivering the required functionalities [78]. Basically, functions are inter-connected in a way that the output of one function can be fed as input to one (or more) functions, which carry out additional operations. Researchers and practitioners have been working on mechanisms and algorithms to better support such function composition, as many FaaS frameworks do not natively support it.

Currently, most well-known cloud providers have proposed their own solutions for FaaS workflows, such as AWS Step Functions, Google Workflows. As regards the frameworks targeting the edge of the network and the continuum, Faasm [31] supports functions chains, while Sledge [33] supports workflows modeled as directed acyclic graphs. OpenWolf [79] extends OpenFaaS to provide a workflow management system for serverless functions in the continuum. Other works, while not proposing novel FaaS engines, present new systems to orchestrate serverless workflows on top of multiple FaaS platforms (e.g., [80, 81]).

A critical issue in managing FaaS workflows regards data passing between functions. Indeed, moving data can introduce non-negligible overhead and should be optimized. Various approaches have been considered, including direct function-to-function communication, the use of shared storage and function co-location, as discussed and evaluated, e.g., in SONIC [74]. To reduce such communication overheads, researchers have also considered a different strategy based on function fusion, where multiple functions are fused into one by merging their source modules (e.g., in WiseFuse [82] and FUSIONIZE++ [83]).

Scheduling and resource allocation for serverless workflows also require specific attention. For instance, Rastegar et al. [84] introduced Enex, a scheduler for serverless function chains that adheres to the deadlines set for each task. Their approach is limited to tasks arranged in a linear chain, where each function’s execution depends on the complete and successful execution of the preceding one, hence this method does not necessarily accommodate workflows with more complex task structures. To address parallel execution of tasks, Exton and Read propose Raptor [85], a distributed scheduling service designed to integrate with existing frameworks and address the challenges posed by parallel workflows. It not only focuses on reducing cold start times and improving fault tolerance, but also handles parallel processing patterns like fork-join and map-reduce, both modeled as directed acyclic graphs (DAGs). The fork-join pattern is modeled as a parallel processing job with a shared dependency, while the map-reduce pattern DAG is defined by the data dependencies among functions. However, Raptor is designed for clusters and does not take latency among nodes into account.

Minimizing execution time is a key QoS objective, as highlighted in [86,87,88]. In [86], the authors focus on optimizing the placement of function chains within edge-cloud systems, with the primary goal of reducing completion time. Similarly, Mahdizadeh et al. [87] pursue this objective by proposing a dynamic resource provisioning and allocation approach for edge FaaS environments. They model workflows as DAGs and developed a mechanism, inspired by course allocation systems, to assign multi-user workflows to limited resources, prioritizing tasks to minimize execution time. HEFTLess [88] is an orchestration service to run a set of serverless workflows across the compute continuum. It integrates a function scheduler that leverages two deployment modes, predeployed and undeployed, where the latter incurs into higher delays because the function code needs to be downloaded and deployed before being executed. The scheduling problem is formulated as a Binary Integer Linear Programming optimization model, taking into account workflow constraints and the limitations of compute continuum resources, with the goals of optimizing the completion time and monetary cost of executing the entire set of workflows. To address the high resolution time of the optimal formulation, a lightweight scheduling heuristic is also proposed. While HEFTLess represents an interesting solution specifically designed for the compute continuum, it might suffer from the centralization of the scheduling decisions.

Sustainability

So far, research on serverless computing has primarily focused on metrics related to performance and monetary costs, with limited attention given to sustainability aspects. However, there is a growing interest in integrating energy efficiency and awareness into serverless systems [89]. A significant concern is the energy consumption of functions on cloud infrastructures. Data centers, which power these functions, consume nearly 500 terawatt-hours (TWh) annually,^{Footnote 3} accounting for 2% of global energy use, with this figure set to rise significantly in the coming years, mainly due to power-intensive generative AI. Notably, the average power usage effectiveness (PUE), the ratio of total data center power to server power, is 1.56 in 2024.^{Footnote 4}

While serverless computing can reduce inefficiency due to its flexibility, several issues must be addressed to optimize energy consumption and reduce carbon footprints. It is crucial to identify where and how energy is consumed in FaaS environments, focusing on the contributing mechanisms. Energy inefficiency in serverless computing mainly originates from the programming and deployment models, which require isolation for ephemeral and stateless functions. Consequently, significant energy consumption occurs during the initialization and virtualization of their execution environments [90]. This limitation is even more evident in edge-to-cloud applications, where energy efficiency is particularly critical at the edge of the network [7]. In such scenario, computing nodes often have limited power capacities due to being battery-powered or resource-constrained devices. It is clear that a FaaS system incorporating such energy-constrained devices must consider energy efficiency during scheduling, offloading and migration activities to maximize device lifespan, reduce battery consumption and degradation, and minimize the need for frequent battery replacement or recharging. In addition, edge data centers cannot exploit the economy of hyperscale cloud data centers toward zero-carbon emissions, as targeted by major cloud providers.

Architectural design techniques for serverless applications play a crucial role in optimizing energy consumption and efficiency. Conventional power management techniques, such as power capping or hardware resource management, are challenging to adopt in edge-to-cloud distributed FaaS systems, as functions resource and energy footprint are highly variable and distributed across many components. Therefore, sustainable serverless computing requires new approaches, which we will analyze in the following.

Shifting to green locations. Serverless functions present unique opportunities to reduce the computing carbon footprint by shifting workloads across locations and time thanks to their location independence and flexible programming model. While computation migration can be challenging for typical cloud workloads, serverless computing simplifies this task considerably compared to traditional cloud environments. For example, Chadha et al. leverage location independence in their GreenCourier platform [91], which executes functions in carbon-friendly locations to improve carbon efficiency. A similar but complementary approach involves running functions on nodes powered by renewable energy sources like solar and wind, despite their intermittent nature. This concept is explored by Aslanpour et al. in their framework faasHouse [92], which uses resource sharing through function offloading. Consequently, minimizing energy consumption becomes even more critical, as effectively utilizing green energy is essential, given its intermittent availability and free cost.

Approximate computing. In many scenarios, exact calculations require substantial resources, while a certain degree of approximation is acceptable. Allowing for some approximation can significantly enhance performance and save energy, while still delivering results within acceptable accuracy levels. Approximate computing is an energy-efficient design approach for digital systems [93], particularly useful in applications where some computational inaccuracy is tolerable, like multimedia content processing (e.g., audio, video, images), recognition tasks, and data mining. Therefore, it can be effectively employed in applications where a less accurate result is sufficient for their purpose. Approximate computing has started to be used as a design approach also in sustainable serverless computing. For example, in [89], Patros et al. provide an example of a real-time video analytics application that detects objects on different frames of a video stream, where distinct deep neural network models from a portfolio can be applied to each video frame to optimize detection accuracy. An extension of Serverledge [94] has been proposed to support energy-aware scheduling with the ability of choosing among multiple function implementations at run-time, trading off energy savings with approximate computation results.

Learning-based energy management. Serverless functions are often repeatedly invoked and with nearly identical execution characteristics. This enables the use of online statistical learning techniques that learn incrementally from past executions. The predictability of these invocations has already been successfully applied in various aspects of FaaS resource management, such as keep-alive strategies [95, 96] and snapshot optimizations [97]. Leveraging this predictability can facilitate the development of AI-driven energy management solutions, for example by predicting a function energy footprint based on other similar functions.

Energy- and carbon-aware scheduling. Serverless functions placement in the edge-to-cloud continuum poses new challenges in terms of energy-efficient scheduling and resource management. The diverse and resource-constrained nature of edge devices necessitates the development of innovative techniques to optimize the placement and execution of serverless functions, with a focus on minimizing energy consumption. Most well-known serverless frameworks, such as OpenFaaS and OpenWhisk, and cloud services, such as AWS Lambda and Azure Functions, are primarily designed to be energy-agnostic. The same observation applies to research prototypes designed for FaaS at the edge, such as Colony [25], Faasm [31], and tinyFaaS [34]. So far, most works in the sustainable serverless field studied how to place and schedule function invocations in an energy-efficient manner. Enex [84] is an energy-aware serverless scheduler designed to minimize energy consumption in a clustered environment by solving an optimization problem that assigns chains of functions with predefined deadlines and computational requirements. Tsenos et al. [98] propose a similar deadline-based approach. Their solution aims at minimizing the energy consumption by placing function containers in a cluster according to various metrics and historical data, function performance requirements, and workload type. Their scheduling algorithm can also apply Dynamic Voltage and Frequency Scaling (DVFS) techniques to the cluster nodes in order to reduce the power footprint of the cluster. Another deadline-aware approach is studied by Verma et al. in LEASE [99], a dynamic resource scheduler tailored for edge serverless environments that manages strict latency requirements. LEASE dynamically adapts to fluctuating workloads by making energy-aware decisions exploiting horizontal offloading. Workload is migrated from over-provisioned edge nodes to under-provisioned peer nodes, considering the expended energy in the process while ensuring that service deadlines are met.

However, the deadline-sensitive strategies mentioned above are not specifically designed for the Continuum, which currently lacks energy-aware scheduling algorithms designed on purpose. Research on this topic is still in its early stages. Calavaro et al. [94] address this gap by proposing an energy-aware scheduling and offloading policy for serverless functions in the edge-to-cloud continuum. The proposed solution in implemented in Serverledge [23], supporting energy-efficient function execution by leveraging function offloading and function variants to extend the lifespan of battery-powered nodes. The platform utilizes a heuristic scheduling policy that determines function placement based on where a FaaS node’s battery level falls between predefined thresholds. Depending on the specific range in which the battery level is situated, the policy dynamically chooses the appropriate action – such as regular function execution, or executing a less energy-intensive version of a function, or offloading the workload to a higher-energy node – thereby optimizing energy consumption and prolonging the operational life of battery-powered nodes.

Another work that considers battery-equipped nodes and aims to minimize the overall system’s power consumption is faasHouse [92]. It is an energy-aware scheduler for edge serverless systems that leverages edge nodes to execute functions close to users. faasHouse focuses on battery-operated edge nodes powered by renewable energy and uses an imbalanced energy-minimizing algorithm to allocate functions to these nodes efficiently. While faasHouse scheduler exploits green energy input sources, GreenCourier [91] is a carbon-aware scheduling framework that uses real-world \(\mathrm {CO_2}\) emissions traces to efficiently schedule serveless functions across geographically distributed regions. Table 2 compares the aforementioned scheduling algorithms along multiple dimensions, such as decentralized approach, placement mechanism, function composition, energy measurement metric, algorithm scheduling goal, and prototype implementation.

Cold Start Reduction. Cold starts are a key factor contributing to energy consumption in serverless environments, therefore their reduction can positively impact on energy efficiency in FaaS systems. As surveyed in [13], many studies have targeted this challenge, with the goal to minimize not only cold start delays but also their occurrence. For instance, the research works in [100, 101] primarily focus on managing the transitions between cold and warm states. Suresh et al. [100] propose to prevent cold starts by reserving a few extra containers in a warm state to effectively manage workload fluctuations. Similarly, in Fifer [101] containers are spawned in advance to avoid cold start delays. On the other hand, researchers also have started investigating cold start minimization through ML techniques. For example, ATOM [102] utilizes a DRL policy to predict cold starts. A two-layer adaptive approach to tackle this issue is proposed by Vahidinia et al. [103]. They utilize a RL policy in the first layer to detect function invocation patterns, and a Long Short-Term Memory (LSTM) neural network to predict when to keep warm containers, according to the first layer information. To the best of our knowledge, the above techniques have been not yet applied in FaaS systems for the compute continuum and their integration can represent an interesting feature.

Security and Privacy

FaaS systems and applications, like almost every computing system, can be vulnerable to cyber attacks. Clearly, the concerns can only get worse when considering geographically distributed deployments. Security issues of FaaS systems have received less attention so far compared to performance- or energy-related aspects. However, as evidenced by early research into specific security concerns [104, 105], this is an aspect we cannot neglect.

Serverless applications rely heavily on inter-function communication and integration with a range of different systems, including APIs and storage. This expands the attack surface and may introduce new vulnerabilities into the overall system. Additionally, executing functions across the Continuum introduces a deeper range of security threats due to the highly distributed nature of the environment and the necessary use of wide-area networks [106, 107]. Furthermore, the proliferation of IoT devices and sensors in the edge computing ecosystem also raises significant privacy concerns, as functions running at the network edge may need to transmit privacy-sensitive data over insecure network links, further heightening security risks. Indeed, such devices often collect and transmit sensitive data, such as video and audio streams, which could be vulnerable to unauthorized access or misuse [108]. While cloud providers offer comprehensive data security solutions, the risk of data leakage during transmission and storage at the edge remains a critical issue.

Morabito et al. [107] propose an approach, based on osmotic computing, to secure the execution of serverless workflows in the continuum, focusing on function access control, communication security, secure storage, and secret distribution. Ayed et al. [109] propose FogProtect, a dynamic and self-adaptive approach that combines different technologies to protect data in the cloud-to-edge continuum, such as data usage control, data protection policy management, service management, and risk assessment. While this solution does not explicitly address serverless workflows, it could be applied to this scenario.

For serverless functions, a major challenge lies in the weak resource isolation provided by lightweight virtualization techniques. In general, a trade-off must be identified between quick startup time and isolation level. For instance, VMs offer better isolation than containers, but their startup times are definitely higher. To address this issues, different solutions for lightweight and secure environments have been recently proposed (e.g., based on WebAssembly or unikernels, see Sect. 5.1). Moreover, even though functions are isolated by being deployed in containers, malicious code can still activate unauthorized functions. Therefore, merely isolating the software execution is not enough; network isolation measures must also be implemented. For instance, Golec et al. [110] present iFaaSBus, a security- and privacy-based serverless framework. Leveraging IoT, machine learning and serverless computing, iFaaSBus is designed with use cases related to COVID-19 pandemic in mind. In their work, the authors enforce privacy by providing security and reliability for IoT communication networks using JWT, TLS, and OAuth\(-\)2.0 authorization protocols.

An alternative approach to achieving higher levels of security in serverless computing lies in hardware-based Trusted Execution Environments (TEEs). TEEs (e.g., Intel Software Guard Extensions (SGX), AMD Secure Encrypted Virtualization (SEV), and RISC-V Keystone) provide robust isolation by encapsulating functions within enclaves, which enforce fine-grained, hardware-level protection, safeguarding sensitive data and code from vulnerabilities in the operating system, other applications, and even physical tampering.

Although TEEs come with limitations that hinder their seamless integration into serverless computing platforms, a few solutions have been proposed to enhance their adoption in this context. For instance, the unidirectional isolation model of TEEs permits enclave code to access untrusted memory, creating security vulnerabilities [111]. For this reason, Cloister [112] proposes bi-directional hardware isolation for enclaves, and introduces a monitor enclave that securely validates system calls and their return values, isolating these interactions from both the operating system and the sandboxed enclave.

PSL [113] is a lightweight, secure, and stateful FaaS framework designed for TEEs. It enables support for multiple programming languages and hardware enclaves (e.g., Intel SGXv2 and AMD SEV) through a secure in-enclave WebAssembly runtime. In addition, the runtime not only isolates itself from application workers, but also enables secure state persistence in untrusted storage, as well as a scalable and efficient eventual state consistency. Another notable development is Occlum [114], a FaaS framework that leverages Software Fault Isolation (SFI) to create lightweight enclaves on secure hardware, although focuses solely on stateless computations and is tailored specifically to Intel hardware extensions.

Another issue, especially for commercial FaaS offerings, regards the lack of robust enclave resource accounting, which is crucial for both transparency and billing. This is addressed by S-FaaS [115], which introduces transitive attestation and contributes a secure resource measurement mechanism to bill clients accurately using Intel TSX extensions.

Serverless computing, with its flexible and scalable nature, has found diverse applications across various domains, including, e.g., Internet of Things (IoT) and Artificial Intelligence (AI) on which we focus in this section.

The FaaS paradigm offers notable advantages for IoT applications, extending beyond its initial design for cloud environments. One of the key benefits is the ability to deploy FaaS platforms closer to the sensors and actuators within edge and fog computing layers. This proximity significantly reduces latency, which is crucial for real-time, mission-critical applications, especially in environments where internet connectivity might be unreliable. In situations where intermittent connectivity is acceptable, functions can be executed across multiple layers, utilizing traditional cloud-based serverless platforms that provide virtually unlimited resources. This approach is particularly effective in managing the large volumes of IoT data generated by sensors.

Several use cases of serverless computing in IoT are highlighted in the literature [8]. For example, smart environments such as smart cities and intelligent transportation systems benefit significantly from this technology. Additionally, remote and extreme edge environments [92, 116], like those in smart farming, leverage serverless computing to monitor and manage diverse conditions. Monitoring applications using IoT sensors are also prevalent in industrial settings. For example, in [117] Bujari et al. describe a serverless application designed for predictive maintenance within Industry 4.0 frameworks. This application processes data from industrial IoT sensors at the edge to detect equipment anomalies, enabling timely alerts and maintenance actions. By processing data locally rather than sending it to the cloud, this approach minimizes latency and enhances operational efficiency.

AI/ML applications are among the most popular FaaS applications in the continuum [118]. Traditionally, ML models are trained in centralized cloud data centers, with inference possibly performed at the edge. However, recent advancements have demonstrated that model training and inference can occur across different layers of the continuum [119, 120], spanning from cloud to edge. Data can be partitioned, distributed across various levels, and then aggregated, paving the way for Federated Learning (FL) in the cloud-to-edge continuum. In this scenario, multiple devices use their local data to train a shared model and only share model updates with a central server, avoiding the exchange of raw data.

As a result, new and challenging distributed intelligence application scenarios are arising in the compute continuum [121]. For instance, researchers have proposed new FaaS frameworks for federated learning tasks, such as FLoX [122] and RuralAI [116], both built on top of funcX [29]. Another notable framework is FedLess [123], which enables training and inference of DNN models on heterogeneous FaaS platforms. A similar approach is adopted also in [124], where the authors propose a platform that combines the edge-cloud architecture with DNN layer distribution over the cloud-to-things continuum to optimize latency. Conversely, Loconte et al. in [125] propose an approach for expanding the continuum toward IoT devices by running training or inference tasks directly on them, allowing serverless functions to run on IoT, edge, and cloud nodes with minimal to no code modification by invoking them through a uniform interface.

As shown above, a significant amount of work has been carried out in recent years to better accommodate serverless functions in the compute continuum. Several issues attracted researchers’ attention, ranging from low-level optimization of function sandboxes to strategies for state and workflow management. Nonetheless, while advancements and improvements have been proposed to address each issue, we lack holistic or unifying solutions able to respond to all (or most) the challenges outlined above. For this reason, efficiently running FaaS systems in the continuum remains an open problem. In the following, we summarize key open challenges that motivate further research on the topic.

Frameworks and libraries. Although different frameworks emerged for FaaS in the continuum (e.g., Colony [25], Serverledge [23, 24]), none of them addresses all the key issues we identified. For instance, both Colony and Serverledge support function offloading, but other approaches (e.g., Faasm, Sledge) presented efficient sandboxing techniques based on WebAssembly, which could benefit function deployment on the network edges.

Resource management. Efficient resource provisioning has been identified as a key challenge for FaaS systems since their first appearances, and the issue only gets more evident in the continuum. A large body of work investigated strategies to effectively schedule workloads at various levels of the infrastructure (e.g., through function offloading). However, solutions presented so far have one or more of the following limitations: (i) they are not integrated in any of the FaaS frameworks available for the continuum (or the Edge), and their applicability is thus limited; (ii) they include assumptions that do not necessarily hold in the continuum (e.g., granted resource availability and network connectivity, homogeneous hardware, stable energy supplies), or have not been evaluated in large-scale infrastructures yet; (iii) they target single and/or stateless serverless functions, neglecting the additional challenges posed by state management and function composition. All these issues call for further investigation.

Emerging non-functional requirements. Systems and applications are increasingly evaluated with respect to multiple non-functional requirements, besides traditional performance indicators (e.g., carbon footprint, security capabilities). This trend can be observed in traditional cloud-like environments, and it becomes even more critical in the continuum. Nonetheless, awareness of such issues and mechanisms specifically focused on these aspects are still not integrated in all the FaaS systems mentioned above.

For instance, sustainability aspects are increasingly important for environmental and economical reasons, and we mentioned several research proposals aiming to tackle various concerns (e.g., reducing energy footprint of serverless functions, dealing with limited energy availability of battery-powered nodes). However, these solutions are usually tailored to specific scenarios and systems. In this regard, more effort would be necessary to develop tools that support monitoring and management of energy consumption across different implementations and deployments. These tools would be fundamental to ease the integration of sustainability-oriented approaches in the FaaS frameworks.

Programmability. FaaS in the continuum is being adopted for different application scenarios, as explained in Sect. Applications. Nevertheless, developing FaaS applications, especially if targeting the continuum, remains a non-trivial activity. Indeed, the existing frameworks for the continuum support a limited set of programming languages for function definition, compared to cloud-oriented frameworks. On the one hand, this issue potentially increases the effort required for development. On the other hand, this issue limits the portability of applications among different systems. The situation is even more challenging when considering function composition and workflows. First, not all frameworks support such composition. Moreover, those supporting composition rely on different specification languages for workflow definition.

Initial effort to address this issue has led to some interesting contributions. For instance, Li et al. [126] proposed UniFaaS, a framework built on top of funcX [29] that features a unifying programming interface to run serverless workflows over federated, heterogeneous FaaS systems. A similar proposal is CODE [127], which aims to streamline serverless application development by means of unified interfaces. However, CODE mainly targets cloud-based FaaS providers. The same group also proposed AFCL [128], a provider-agnostic language to define serverless workflows. However, to the best of our knowledge, execution of AFCL-defined workflows is not yet supported by any of the major FaaS frameworks.

For these reasons, we expect more work in the future to ease the adoption of FaaS in the continuum for application development, especially as regards the identification of languages and tools that can create shared interfaces towards the existing, different frameworks.

Datasets and simulators. Focusing on tools and artifacts for research on the topic, an important role is played by publicly available simulation software and data for benchmarking and evaluation of novel solutions. While we have seen recent contributions in this direction (e.g., the Globus Compute dataset [129], or SimFaaS [130]), we expect more effort in this regard.

In conclusion, this paper analyzed the key challenges faced for FaaS deployment and execution in the compute continuum. We identified and discussed several research trends. However, as discussed above, significant research gaps still exist, and we expect this topic to remain active in the near future.