Serverless Functions in Cloud–Edge Environments: A Comprehensive Critical Review and Taxonomy

Abstract

Cloud–edge continuums are driving the shift of cloud-native applications from centralized data centers to latency-, mobility-, privacy-, and energy-saving applications. The serverless architecture provides an attractive “Function-as-a-Service” (FaaS) model in this transition, as it is driven by events, elastic and fine-grained, and controlled by the platform. But introducing a mix of heterogeneous edge nodes, fog/MEC resources, regional clouds, and hyperscale data centers creates a seemingly simple FaaS deployment problem to solve with a set of multi-objective orchestration challenges: runtime selection, autoscaling, cold start mitigation, placement, migration, workflow coordination, state management, trust, cost, energy, and carbon. In this article, we provide an extensive critical review of serverless functions in cloud–edge environments. While some surveys are narrowly focused on aspects of autoscaling, offloading, IoT, or security, the review brings together architectural evolution, runtime mechanisms, platform ecosystems, governance issues, sustainability issues, and emerging applications using AI. It builds a multidimensional taxonomy ranging from runtime systems, autoscaling, cold start mitigation, function placement, and offloading/migration, to workflow orchestration, state and data management, intelligent scheduling, security, sustainability, and industrial serverless platforms. It also presents a built-in conceptual model that connects application needs, runtime environment, orchestration intelligence, governance policies, and system-level results. The synthesis reveals that cloud–edge serverless systems need accountable placement, state-aware workflows, reproducible benchmarking, trustworthy orchestration, and carbon-aware lifecycle control, which can be achieved only by going beyond latency and elasticity. The paper ends with research directions on adaptive, interoperable, explainable, and sustainable serverless systems on the cloud–edge continuum.

1. Introduction

Cloud, edge, artificial intelligence (AI) and the Internet of Things (IoT) are transforming the landscape of distributed computing. While centralized cloud infrastructures still provide elastic capacity, maturity and wide platform services, they have become inadequate for applications demanding low latency, local data processing, mobility support, privacy protection and context-aware decision-making capabilities. In the context of emerging workloads, including autonomous systems, industrial digital twins, augmented reality, smart healthcare, intelligent transportation, real-time video analytics and large-scale cyber-physical systems, computation is required to be executed closer to data sources and end-users than only in the remote cloud regions [1,2,3,4]. This trend has led to the proliferation of architectures that move away from cloud-centric and towards cloud–edge continuums, where devices, edge nodes, fog/MEC infrastructures, regional clouds and central clouds work together as a distributed execution fabric.

Serverless computing is one of the most powerful programming and execution paradigms in the cloud-based world. The Function-as-a-Service paradigm lets the developer deploy small event-driven functions, while the platform provisions, scales, fails and controls them. The model enhances agility in development, reduces the burden of infrastructure management and allows for fine-grained scaling and billing. These properties make serverless computing appealing for apps that have bursts of activity, that are event-driven, and that are triggered by data. Serverless functions are known for being stateless, short-running, pay-per-use, and automatic scaling, as well as having managed event sources [4,5,6].

The extension of serverless computing into cloud–edge environments changes the problem substantially. Edge resources are CPU, memory, storage, energy, connectivity and geographically distributed; heterogeneous; and administratively diverse. When a function is pushed to the edge of a hyperscale cloud, it could face cold start delays, image distribution overhead, limited warm container availability, network jitter, or state placement issues. However, cloud–edge serverless execution is not only about the number of function instances to be created but also about where the functions have to run, how to route the requests, which state should be kept local, when to migrate the functions, how to establish trust, and whether the benefits of serverless execution justify the energy, carbon and cost overheads [7,8,9,10].

There has been significant research progress in the last few years on individual components of the field. Studies on autoscaling include reactive, predictive, and hybrid policies [11]; cold start studies include pre-warming, lightweight virtualization, data reuse, and invocation prediction [12]; placement and offloading studies include latency-aware and QoS-aware execution across cloud and edge sites [2]; workflow studies include function composition, data movement, and orchestration overhead [3]; and security studies include Denial-of-Wallet exposure, side channels, provenance, and secure edge workflows [13,14]. While serverless functions have traditionally been used for basic web backends, parallel work has expanded their usage to federated learning, IoT pipelines, digital twins, MLOps, and domain-specific analytics [7,15,16,17].

In spite of these advances, there is still a lack of integration in the literature. Numerous studies focus on optimizing a single mechanism like autoscaling or offloading but not taking into account the interaction with cold starts, workflow state, energy usage, trust policy, platform interoperability, or industrial deployment constraints. Most of the existing surveys are limited to a specific aspect of the problem, such as autoscaling, function offloading, integration of IoT devices, or cloud-to-edge computing, and do not provide a comprehensive understanding of the interplay between these mechanisms to ensure a seamless lifecycle for cloud–edge serverless execution [4,9,11,18]. This fragmentation makes it difficult to get a handle on the field; there is a need for a consolidated review that will showcase not only which techniques exist, but how they are connected, where they fail, what assumptions are required to deploy them and what design principles should inform future platforms.

This article fills that void by redefining the cloud–edge serverless computing as an orchestration and governance issue. The main idea is that the serverless function in cloud–edge environment should be considered in terms of interacting goals: latency, scalability, data locality, reliability, security, trust, operational cost, energy consumption, carbon exposure, and reproducibility. If a scheduler can reduce latency but increase the idle warm pools, egress cost, carbon intensity and/or security risk, it cannot be considered to be the optimal scheduler. Likewise, a platform that offers elasticity but lacks strong state management, observability, and interoperability is unlikely to meet industrial needs. A critical review is thus required to transcend descriptive summaries and reveal the trade-offs, immaturities, and tensions in the field.

1.1. Motivation and Research Gap

There are three reasons for this review. First, cloud–edge serverless computing is fast emerging as a real consideration because of the increasing need for elastic computing at the edge of the data, such as for AI, IoT event streams, real-time analytics, and distributed cyber-physical applications. Second, the conceptual frameworks that organize the research is lagging behind it. While all the concepts are important, they are discussed individually and are operationally intertwined. Third, the progress of industrial serverless platforms and open-source FaaS frameworks are also moving in parallel with academic research, necessitating the need to compare mechanisms with deployment realities.

It is not a trivial problem to identify that there is no other survey that covers serverless. The missing link is a cross-layer, critical synthesis of the behavior of serverless functions as lifecycle managed entities in distributed cloud–edge infrastructures. It must link the architectural underpinnings, runtime systems, autoscaling, placement, workflows, security, sustainability, platform ecosystems, and application domains together. It should also highlight literature that is well developed, less developed, and literature that needs to be focused on future research that is reproducible and industrially relevant.

1.2. Guiding Review Questions

RQ1. What architectural patterns and platform ecosystems enable serverless functions across cloud–edge environments?

RQ2. How do existing approaches manage autoscaling, cold start mitigation, function placement, offloading, migration, and request routing under edge constraints?

RQ3. How are serverless workflows, stateful execution, and data-intensive functions supported across heterogeneous cloud–edge infrastructures?

RQ4. What roles do AI, federated learning, and intelligent scheduling play in cloud–edge serverless orchestration?

RQ5. How do security, privacy, trust, provenance, and Denial-of-Wallet exposure affect serverless function execution across distributed sites?

RQ6. How are energy consumption, carbon awareness, cost, and sustainability incorporated into serverless function lifecycle decisions?

RQ7. What unresolved research, benchmarking, interoperability, and industrial-deployment challenges must be addressed to mature the field?

1.3. Major Contributions

C1. Extensive critical analysis of cloud–edge serverless computing. The review brings together the recent progress in serverless computing in the cloud, edge, fog and MEC domains, and connects the mechanisms proposed by cloud-native platforms with distributed systems and edge orchestration research.

C2. Multidimensional classification of serverless mechanisms. The paper proposes a taxonomy that categorizes research based on runtime systems, autoscaling, cold start mitigation, placement, offloading, migration, workflow orchestration, state management, intelligent scheduling, security, sustainability, platform ecosystems and application domains.

C3. Critical review of assumptions, maturity and readiness for deployment. Rather than describing each study individually, the review critically examines scalability assumptions, evaluation limitations, reproducibility gaps, industrial relevance, and trade-offs involving latency, cost, energy, carbon emissions, data locality, reliability, and trust.

C4. Integrated conceptual framework. The paper introduces a framework that establishes a relationship between application needs, runtime context, orchestration intelligence, governance policies, and system-level outcomes, and how cloud–edge serverless decisions relate to each other across the function’s lifecycle.

C5. Next-generation platform research agenda. The review points to future directions such as trustworthy orchestration, carbon-aware scheduling, stateful edge functions, cross-provider interoperability, explainable AI-driven resource management, reproducible benchmarking and sustainable cloud–edge infrastructures.

1.4. Organization of the Paper

The rest of the article is structured as follows: Section 2 sets the boundaries for the review, outlines the literature identification strategy, classifies the evidence and describes the research landscape. Section 3 builds on the conceptual elements of cloud–edge serverless computing. Section 4 compares this review with the literature on surveys. The architectural evolution and suggested taxonomy are presented in Section 5. Each of the Section 6, Section 7, Section 8, Section 9, Section 10, Section 11 and Section 12 discusses key mechanisms in a critical manner: runtime systems, autoscaling, cold starts, placement, workflows, state management, AI-driven orchestration, security, and sustainability. Section 13 explores the industrial serverless platforms and open-source serverless ecosystem. Evaluation, benchmarks and reproducibility are the topics of Section 14. The integrated conceptual framework and design principles are proposed in Section 15. In Section 16, lessons are synthesized. Research challenges and future directions are given in Section 17. Section 18 discusses practical and industrial implications. Threats to validity and review limitations are presented in Section 19, and the paper is concluded in Section 20.

2. Review Scope and Literature Identification

This article is framed as a comprehensive critical review rather than a formal systematic literature review or statistical meta-analysis. This choice directly reflects the objective of the paper: to synthesize a field that is constantly changing and multidisciplinary, with evidence spread across several areas such as serverless computing, cloud-native systems, edge computing, IoT, federated learning, security, sustainability, workflow orchestration and industrial platform engineering. While the review can be a strictly protocol-driven exercise of counting publications and mapping narrow topics, the present review cannot be so narrowly focused, as cloud–edge serverless computing features interactions across layers rather than any single intervention or evaluation metric [19].

The major search window focused on the literature from 2018 through 2026, which was when these concepts of edge serverless, cloud continuum orchestration, WebAssembly runtimes, Knative-style platforms, and carbon-aware cloud research emerged. Earlier works were kept only where they laid the groundwork for new concepts, such as the critical review methodology, scientific serverless workflows, and early serverless architectures based on containers. Papers that directly impact on the execution of FaaS, cloud–edge placement, cold start mitigation, platform/runtime design, workflow/state management, security, sustainability, and reproducible evaluation were prioritized. If the terminology was unclear, studies were only included if it impacted the serverless function lifecycle, not generic cloud, fog, container or DevOps operations. There was a separation of industrial sources from peer-reviewed evidence; these latter were used only for a comparison of the practical capacities of the platforms.

The review is carried out through a transparent, reproducible and critically interpretative process of literature identification. The iterative search of major scholarly databases and publisher libraries was used to identify the relevant literature, such as ACM Digital Library, IEEE Xplore, ScienceDirect, SpringerLink, Scopus, Web of Science and Google Scholar. Searches were performed by merging serverless computing and FaaS terms, as well as cloud–edge concepts and mechanism-specific terms. Examples of representative search expressions were “serverless computing” AND “edge computing”; “Function-as-a-Service” AND “cloud-edge”; “serverless functions” AND “function placement”; “serverless edge computing” AND “cold start”; “serverless” AND “autoscaling”; “FaaS” AND “workflow orchestration”; “serverless” AND “federated learning”; and “serverless” AND “sustainability” OR “carbon-aware scheduling”.

Peer-reviewed journal articles, leading conference papers, influential survey papers, and technically significant papers that describe mechanisms directly relevant to the execution of serverless applications in the cloud–edge environment were prioritized. Only when materials were industrial documents, white papers, or platform materials that clarified the capabilities and/or limitations of major serverless platforms were they considered; these were not considered to be peer-reviewed empirical evidence. When they set up important concepts, like Function-as-a-Service, scientific serverless workflows, and cloud–edge continuum computing [5,6,20], they retained the foundational works.

The review is intentionally not comprehensive of any broad cloud–edge, fog computing, DevOps, or container orchestration studies unless they are directly relevant to the execution of serverless functions, design of the runtime substrate, orchestration mechanisms, governance of the edge, security, or sustainability. This is significant because the manuscript is not a general review of cloud–edge–fog. It focuses on the serverless function lifecycle in cloud–edge environments, including trigger, place, warm, scale, migrate, compose, secure, monitor, and evaluate. The scope of this review, the inclusion priorities, and the exclusion boundaries are defined in

Table 1. Review scope, inclusion priorities, and exclusion boundaries.

Dimension	Included in This Review	Excluded or Used Only as Background
Core topic	Serverless functions, Function-as-a-Service, event-driven execution, cloud–edge FaaS, edge serverless platforms.	General cloud computing or edge computing without a serverless/FaaS connection.
Runtime mechanisms	Autoscaling, cold starts, runtime systems, containers, microVMs, WebAssembly, request routing, function lifecycle control.	Generic VM/container scheduling unless it shapes serverless runtime behavior.
Placement and orchestration	Function placement, offloading, migration, topology-aware scheduling, workflow orchestration, state/data locality.	General task offloading without relevance to functions, triggers, or serverless workflows.
Governance and sustainability	Security, privacy, trust, provenance, Denial-of-Wallet risk, energy-aware and carbon-aware execution.	Broad zero-trust or green cloud studies not connected to serverless function decisions.
Evidence type	Peer-reviewed articles, leading conference papers, influential surveys, seminal works, and platform materials for industrial comparison.	Non-technical commentary, marketing material, and unsupported claims.

, and are used to limit the scope of the manuscript.

2.1. Analytical Review Strategy

Thematic coding and critical comparison of the selected literature were used for analysis. The studies were categorized based on the main mechanisms they employed, such as runtime systems, autoscaling, cold start mitigation, function placement, offloading and migration, workflow orchestration, state management, AI-assisted scheduling, security and trust, sustainability, industrial platforms, and application domains. The review within each theme will compare assumptions, control variables, optimization objectives, evaluation settings, metrics, datasets, testbeds, and reported limitations.

Taxonomy is done deductively and inductively. Deductively, the review starts with the questions that guide the review and the serverless function lifecycle: triggering, deployment, scheduling, execution, scaling, interaction with state, composition, monitoring, and termination. Inductively, other categories are derived from the recurring patterns in literature that include warm pool management, topology-aware placement, serverless federated learning, workflow fusion, Denial-of-Wallet exposure, and carbon-aware scheduling. This way, the taxonomy is not forced but is developed based on the conceptual structure of a serverless system and the mechanisms that are repeatedly observed in the studies.

Critical evaluation involves the five common questions: What problem does the study address? What are the assumptions that allow the solution to be feasible? What are the indicators of the claims? What are the compromises that are not mentioned or not fully elaborated? What about the transferability of the approach to heterogeneous cloud–edge environments? These questions assist in differentiating between developed contributions and ideas that are in the early stages and provide a more productive and productive review for Q1 scholarly synthesis. The analytical lenses used in synthesizing the selected literature are summarized in

Table 2. Analytical lenses used to synthesize the literature.

Analytical Lens	Key Questions	Expected Output
Architecture and platform ecosystem	Which FaaS architectures, runtimes, and cloud–edge deployment models are used?	Architectural classification and platform comparison.
Runtime control	How are scaling, warming, routing, and runtime overhead managed?	Mechanism-level taxonomy and performance trade-off analysis.
Placement and mobility	Where should functions execute, and when should they move?	Comparison of placement, offloading, migration, and topology-aware scheduling.
Workflow, data, and state	How are function chains, stateful workloads, and data-intensive pipelines managed?	Identification of state and workflow limitations.
Governance and sustainability	How do trust, security, cost, energy, carbon, and auditability shape function lifecycle decisions?	Cross-cutting research agenda and design principles.

.

2.2. Literature Identification and Evidence Handling

As this article is a comprehensive critical review, the literature identification process is focused on coverage, relevance and analytical value and not necessarily on formal PRISMA counting. However, the review ensures transparency by recording the sources of search, representative search terms, priorities for inclusion, boundaries for exclusion and dimensions for synthesis. The search process may be extended to a PRISMA flow if a target journal requires a formal systematic protocol, including database-specific retrieval counts, removal of duplicate records, and screening of records.

To minimize bias, the review equates recent work with foundational research, and academic mechanisms with industrial platform realities. Although the serverless and cloud–edge technologies evolve rapidly, recent works are given preference, and older works are kept where they present interesting concepts or general lessons that can be reused in evaluations. Survey papers are primarily employed to help place the review and to identify gaps; primary studies are employed to analyze mechanisms, evidence, and trade-offs.

2.2.1. Inclusion and Exclusion Criteria

The inclusion and exclusion criteria underlying the construction of Table 1 are specified as follows: a study was included if it (i) directly concerned the execution, orchestration, or governance of serverless functions (Function-as-a-Service, FaaS) in a cloud, edge, fog, or cloud–edge continuum setting; (ii) reported a mechanism, architecture, empirical measurement, or critical analysis relevant to at least one stage of the serverless function lifecycle (trigger, place, warm, scale, migrate, compose, secure, monitor, evaluate); or (iii) constituted a foundational or methodological work required to ground the review’s methodology, terminology, or a seminal concept subsequently built upon by the reviewed corpus, irrespective of publication year. A study was excluded, or retained only as background material, if it (i) addressed general cloud, fog, or edge computing without a specific, identifiable connection to serverless or FaaS execution; (ii) addressed generic virtual machine or container scheduling, or DevOps tooling, without shaping serverless runtime behavior specifically; (iii) constituted non-technical commentary, marketing material, or an unsupported claim without a verifiable mechanism or evaluation; or (iv) was a duplicate, a preprint superseded by a peer-reviewed version of the same work, or an extended-abstract version of a paper already included in its full form.

2.2.2. Screening Process and Scope

This review is framed as a comprehensive critical review rather than a formal PRISMA protocol systematic review and is accordingly not accompanied by a database-by-database PRISMA flow diagram. Table 24 provides the structural scaffold for such a flow, reporting each screening stage, its purpose, and the field the corresponding count occupies, in support of methodological transparency for readers accustomed to PRISMA-style reporting. The principal reasons full-text-assessed records were subsequently excluded are reported qualitatively as follows: (a) the study’s central contribution concerned generic cloud, edge, or fog resource management without a serverless-specific mechanism; (b) the study addressed container or virtual machine orchestration in a DevOps context unconnected to the FaaS execution model; (c) the study was non-technical, an opinion piece, or vendor marketing material without a verifiable technical claim; or (d) the study was a duplicate, an extended abstract, or an earlier preprint superseded by a more complete peer-reviewed version already included.

2.3. Evidence Classification

The evidence reviewed can be grouped into six overlapping categories: The major studies presented in core cloud–edge serverless include function placement, function offloading, cold starts, scaling, workflows, and edge runtime design. FaaS execution and composition, as well as cold start behavior, can be understood by the serverless cloud-only studies. Edge, fog and cloud continuum works help in understanding the issues of heterogeneity, task offloading, latency minimization and resource constraints. Security and governance works include analysis of trust, provenance, denial of wallet and side-channel risk. Energy and carbon aspects are added by sustainability studies. Last, but not least, industrial and open-source platforms provide practical deployment capabilities and limitations.

Table 3. Evidence categories and their role in the review.

Evidence Category	Representative Focus	Role in the Review
Core serverless cloud–edge studies	Function placement, offloading, migration, edge runtime systems, FaaS orchestration.	Primary synthesis and mechanism comparison.
Serverless cloud-only studies	FaaS programming, cold starts, function composition, workflow execution.	Conceptual support and baseline comparison.
Edge/fog/cloud continuum studies	Latency, mobility, resource management, fog/MEC architecture.	Contextual support for distributed execution constraints.
Security and governance studies	DoW, side channels, provenance, trust, secure workflows.	Cross-cutting analysis of risk and policy-aware orchestration.
Sustainability studies	Energy-aware serverless, carbon-aware fog/cloud, green scheduling.	Cross-cutting analysis of energy/carbon trade-offs.
Industrial platform evidence	AWS Lambda@Edge, Cloudflare Workers, Azure Functions, Google Cloud Functions, Knative, OpenFaaS, OpenWhisk.	Practical platform comparison and deployment readiness discussion.

provides a description of the various types of evidence and their function in the review.

2.4. Descriptive Landscape of Cloud–Edge Serverless Research

This section describes the landscape of cloud–edge serverless research. For the critical synthesis, the corpus was organized descriptively prior to thematic interpretation, in order to have an evidence-informed basis. This mapping is not provided as a formal bibliometric analysis but as a structured presentation of the evidence base that informed the critical review. Following broad contextual items that were not directly related to serverless function execution, runtime substrates, orchestration, governance, security, sustainability, and platform context, the final corpus consists of 134 curated references. These are studies on core serverless topics and carefully curated contextual papers on cloud–edge/fog resource management, container orchestration, AI-driven edge computing, security, sustainability, and cloud–edge applications in specific domains. This coverage is represented in the form of a study-level evidence heatmap in Figure 1, showcasing the extent to which the paper’s evidence is provided for the analysis dimensions covered by the reviewed works.

Core serverless and FaaS sources support the analysis of function execution, runtime management, workflow support, cold start behavior, and edge-oriented FaaS platforms [21,22,23,24,25,26,27,28,29].

Runtime substrate and platform operation sources inform the discussion of containers, cloud-native execution, lifecycle management, migration, and deployment overheads [30,31,32,33,34,35,36,37,38,39,40,41]. Additional sources in this category further clarify the same evidence stream [42,43,44].

Cloud–edge, fog, and continuum resource management studies are used as contextual evidence for placement, task offloading, scheduling, latency, and mobility constraints [45,46,47,48,49,50,51,52,53,54,55,56]. Additional sources in this category further clarify the same evidence stream [57,58,59,60,61,62,63,64,65,66,67,68]. Additional sources in this category further clarify the same evidence stream [69,70,71].

AI-enabled and domain-specific cloud–edge studies provide evidence for emerging application pressure from FL, video analytics, smart systems, digital twins, remote sensing, and cyber-physical workloads [72,73,74,75,76,77,78,79,80,81,82,83]. Additional sources in this category further clarify the same evidence stream [84,85,86,87,88].

Security, trust, and governance studies support the analysis of side channels, data integrity, secure offloading, blockchain-assisted coordination, trustworthy scheduling, and edge–cloud attack exposure [89,90,91,92,93,94,95,96,97,98,99,100]. Additional sources in this category further clarify the same evidence stream [101,102,103,104,105].

Sustainability and cost/energy optimization studies inform the review’s treatment of energy-aware placement, carbon-aware scheduling, and green cloud–edge execution [106,107,108,109,110,111,112].

Additional cloud-native and edge context studies were retained only where they clarified infrastructure or platform assumptions [113,114,115,116]. Figure 2 complements this descriptive mapping by visualizing the reviewed corpus as thematic clusters, influential works, and emerging directions.

The temporal distribution shows that the majority of reviewed works are in the last few years, with a significant group in 2024–2025. This is a testament to the speed at which serverless is moving towards edge orchestration, federated learning, digital twins, containerized platforms and sustainable computing. To support review methodology and early cloud/serverless concepts, works prior to 2018 are retained.

The mapping additionally reveals that the field is uneven. Carbon-aware function warming, stateful edge FaaS, cross-provider interoperability, trust-aware placement, explainable orchestration, and reproducible benchmarking are areas that are still less developed, while autoscaling, cold start mitigation, latency-aware placement, and containerized runtime execution are more mature. This imbalance drives the taxonomy, lessons learnt, and future research agenda of later sections.

Two clarifications regarding Figure 2 are warranted. First, Figure 2 represents a broader thematic and co-citation landscape rather than a plot of the review’s own 134-reference core corpus in isolation; as its caption indicates, it visualizes research themes, influential works, and emerging directions, and its accompanying map statistics report 412 nodes across the visualization, compared with the 134 references formally cited in the core corpus (

Table 4. Descriptive publication year pattern in the expanded evidence base.

Period	Approximate Source Count	Interpretation
Before 2018	5	Foundational context: review methodology, early edge/fog concepts, and early container/serverless foundations retained only when directly relevant.
2018–2020	10	Foundational phase: early containerized serverless, workflows, edge/fog concepts, and cloud-native support studies.
2021–2022	35	Expansion phase: edge/fog scheduling, container management, IoT integration, security, and early sustainability concerns.
2023–2024	65	Acceleration phase: cloud–edge serverless placement, workflows, FL, digital twins, energy, trust, and platform studies.
2025–2026	19	Emerging phase: recent autoscaling surveys, topology-aware platforms, serverless edge warming, secure edge/cloud systems, and future-oriented studies.

). The figure therefore intentionally incorporates a small number of highly influential, frequently co-cited foundational works that fall outside the core 2018–2026 corpus and outside the review’s own reference list, represented as high-influence anchor nodes within their respective thematic clusters. The study of [117], an early and widely cited edge computing vision paper, anchors the runtime systems and platforms cluster, and [118], an early and highly cited survey on mobile edge computing from the communication perspective, is positioned within the cold-start mitigation cluster by the underlying co-citation analysis consistent with the criterion established in Section 2, whereby pre-2018 works are retained only where they ground a methodology or a seminal concept.

Second, regarding the absence of a visibly 2026-labeled node in Figure 2: the reference list does include 2026 publications, including [119] on neighbor-aware container warming, [8] on OpenWhisk-based platforms, and [120] on carbon- and migration-aware scheduling, indicating that the corpus is not without 2026 evidence. Figure 2, however, is a static visualization generated at an earlier stage of corpus curation and does not yet reflect the literature added subsequently. This figure will be regenerated from the updated corpus prior to camera-ready submission.

Figure 3 provides a summary of the critical review methodology and synthesis process that was followed to identify the literature, collect evidence, code the evidence into themes, develop a taxonomy, and synthesize the review findings. The pattern of descriptive publication years of the expanded evidence base is reported in Table 4.

Table 5. Descriptive evidence distribution by research theme.

Theme	Evidence Pattern	Dominant Methods and Platforms	Observed Gap
Runtime systems and platforms	Moderate evidence; strong open-source and cloud-native focus	Containers, Kubernetes, Knative, OpenWhisk, OpenFaaS, WebAssembly, microVMs	Limited cross-platform and edge-scale comparison.
Autoscaling and cold starts	Relatively mature evidence base	Reactive/predictive scaling, warm pools, lightweight runtimes, invocation prediction	Energy, carbon, and security costs of warming are underreported.
Placement, offloading, migration	Growing evidence base	Optimization, QoS-aware policies, topology-aware scheduling, DRL	State migration, trust, and carbon constraints are weakly integrated.
Workflow, data, and state	Moderate but fragmented evidence	DAGs, scientific workflows, function fusion, data-locality patterns	Stateful edge FaaS remains immature.
AI, FL, and intelligent orchestration	Rapidly growing evidence	Predictive ML, DRL, serverless FL, drift detection, digital twins	Explainability, robustness, and real testbed validation remain limited.
Security, trust, sustainability	Emerging and cross-cutting evidence	DoW detection, provenance, attestation, green scheduling, energy measurement	Security and carbon are rarely first-class scheduling constraints.

and

Table 6. Evidence pattern synthesis used in the critical review.

Evidence Feature	Pattern Observed in the Reviewed Corpus	Implication for This Review
Method type	Surveys, prototype frameworks, simulations, optimization models, ML/DRL studies, and platform case studies appear across the corpus.	The review uses critical synthesis rather than statistical pooling.
Evaluation environment	Real cloud testbeds and open-source platforms are used in some studies, but many placement and DRL works rely on simulation.	Reproducibility and external validity are major concerns.
Platform coverage	Knative, OpenWhisk, OpenFaaS, AWS Lambda, Cloudflare Workers, Kubernetes, containers, microVMs, and WebAssembly are recurring platform references.	Platform heterogeneity motivates the industrial comparison section.
Metric frequency	Latency, cold start time, throughput, resource utilization, cost, energy, and SLO violations appear often; carbon and trust metrics are less common.	Future benchmarks should include carbon, trust, and auditability.
Application domains	IoT, FL, digital twins, remote sensing, MLOps, video analytics, industrial systems, and cyber-physical workloads are recurring domains.	Serverless edge computing should be studied beyond web backends.
Underexplored challenges	Stateful edge functions, carbon-aware warming, trust-aware placement, cross-provider portability, and explainable AI orchestration remain weak.	These become central future research directions.

provide a summary of the evidence distribution by descriptive and evidence pattern synthesis, respectively, to support the critical review by major research themes.

3. Conceptual Foundations of Cloud–Edge Serverless Computing

Serverless computing is often described as a cloud service model where the developer provides functions, and the provider manages resource provisioning, scaling, and billing. This definition represents the operational abstraction but it is not complete for cloud–edge environments. The distributed edge model also introduces event routing, runtime selection, function image distribution, state affinity, locality policies, trust constraints, observability, and cross-layer coordination to the serverless model. Thus, cloud–edge serverless computing can be considered as a managed distributed execution model that dynamically distributes small units of computation across heterogeneous sites triggered by events.

The key difference between the traditional cloud FaaS and the cloud–edge FaaS is the execution substrate. Centralized cloud platforms run functions in relatively homogeneous data centers that have rich networking and storage and monitoring capabilities and have been well provisioned for autoscaling. Functions can run on edge servers, gateways, fog/MEC nodes, regional clouds, or central clouds in cloud–edge environments. These sites vary in resource capacity, network reliability, security posture, energy profile and administrative control. The control plane needs to expose enough information about policies to achieve reliable deployment and yet hide some of this complexity from the developers [2,3,121].

The other important base is stateless abstraction and stateful application reality. Typically, serverless platforms promote the use of stateless functions, since they are easier to scale and fail-safe. Cloud–edge applications, however, require local context of the sensor, caching of machine learning models, user sessions, workflow state, and local data stores. In the era of scientific workflows, digital twins, federated learning and data-intensive serverless pipelines, edge FaaS systems are increasingly required to explicitly manage state and data locality [5,15,122].

Cloud–edge serverless systems also change the definition of elasticity. Elasticity typically means scaling up or down the number of function instances in a cloud-only serverless system. Elasticity is part of the continuum that also encompasses geographical elasticity, warm pool placement, request rerouting, edge-to-cloud spillover, function migration, and data-aware scheduling. A function can not just scale, but also move, duplicate, merge, split, or be warmed up in advance at a predicted location [8,10,20,123]. The cloud–edge serverless execution continuum and interaction between distributed execution layers and the serverless control plane are shown in Figure 4.

Table 7. Key conceptual distinctions between cloud-only and cloud–edge serverless computing.

Concept	Cloud-Only Interpretation	Cloud–Edge Interpretation	Key Challenge
FaaS	Event-triggered execution in cloud regions.	Functions execute across device, edge, fog/MEC, regional, and central cloud layers.	Preserving abstraction across heterogeneous sites.
Autoscaling	Create or remove instances based mainly on workload demand.	Scale, route, warm, and place functions while considering edge capacity and mobility.	Avoiding cold starts without wasting energy.
Cold start	Delay caused by runtime creation and dependency loading.	Delay amplified by edge scarcity, image distribution, and limited warm pools.	Predicting demand under bursty and mobile workloads.
Placement	Select cloud region or availability zone.	Choose between device, edge, fog/MEC, regional cloud, or central cloud based on latency, data, trust, and carbon.	Multi-objective placement under uncertainty.
State and data	Use managed cloud storage or external services.	Manage state locality, model caching, consistency, and policy-bound data movement.	Supporting state without losing elasticity.
Governance	Apply cloud IAM, logs, and provider controls.	Coordinate identity, provenance, attestation, DoW defense, auditability, and cross-domain trust.	Turning security and policy into scheduling constraints.

highlights some of the conceptual differences between cloud–edge and cloud-only serverless computing.

4. Positioning Against the Existing Review and Survey Literature

There are a number of survey streams that are applicable to this review. While there are various cloud-native and serverless scaling mechanisms (e.g., reactive, predictive, and hybrid scaling), these mechanisms are generally considered within the context of performance control and do not fully account for edge placement, economic attacks, sustainability, and trust [11,18]. Function offloading surveys highlight the decision factors involved in offloading serverless functions between edge and cloud sites, but they tend to consider latency, bandwidth, energy and privacy as separate variables instead of a problem of lifecycle governance [9].

Other survey streams cover nearby areas. The serverless-IoT reviews focus on the mapping of event-driven IoT integration and deviceless abstractions but offer less insights into the management of function lifecycles, stateful workflows, and cloud–edge governance [1,16]. Perspectives of cloud-to-edge continuum focus on distributed execution and application fabrics but are often agenda-setting rather than mechanism-level syntheses [4,121]. Security-oriented and sustainability-oriented works are important, but they are not necessarily found in the literature on scheduling and runtime [2,124,125,126].

The novelty of the present review is not only being about serverless edge computing. Its value is in combining all these flows into a cross-layer view of the serverless function as a lifecycle-managed, policy-controlled and sustainability-aware execution entity. This is especially significant as it is important to make decisions about the warmth, placement, routing, state, and choice of platform in a coordinated manner, as each decision influences the other in terms of latency, cost, energy, trust, and operational evidence.

Table 8. Positioning of this review against related survey streams.

Review Stream	Typical Focus	Common Limitation	How This Review Extends It
Autoscaling surveys	Scaling metrics, controllers, prediction, Knative-style systems.	Limited treatment of placement, DoW, trust, and carbon.	Connects scaling to warming, placement, energy, cost, and governance.
Function offloading surveys	Decision variables for moving functions across edge and cloud.	Often considers latency/energy/privacy separately.	Builds lifecycle taxonomy including state, workflows, security, and sustainability.
Serverless IoT reviews	Triggers, IoT integration, event processing, device abstractions.	Less emphasis on FL, digital twins, industrial platforms, and governance.	Links IoT triggers to stateful workflows and policy-aware edge execution.
Cloud-to-edge perspectives	Distributed execution fabrics and cloud continuum trends.	Often agenda-setting and less mechanism-specific.	Provides mechanism-level critical analysis and deployment readiness discussion.
Security and trust studies	DoW, provenance, side channels, workflow security.	Often not integrated into placement or scaling models.	Treats security as a runtime scheduling and lifecycle constraint.
Sustainability studies	Energy and carbon in fog/cloud or serverless software.	Often separated from cold start and placement decisions.	Frames sustainability as part of function lifecycle control.

compares this review to other survey streams and explains the additional value of this review and

Table 9. Detailed comparison with representative review streams and surveys.

Review Stream/Representative Works	Scope	Cloud–Edge Focus	Security	Sustainability	Taxonomy	Main Limitation	This Paper’s Improvement
Autoscaling surveys [11,18]	Cloud-native and serverless scaling controllers	Partial	Limited	Limited	Yes	Scaling is treated mainly as performance control.	Connects scaling with placement, warming, DoW, trust, energy, and carbon.
Function offloading survey [9]	Serverless function offloading decisions	Strong	Partial	Partial	Yes	Less integration of workflows, state, platforms, and governance.	Places offloading within a complete function lifecycle taxonomy.
Serverless IoT reviews [1,16]	IoT triggers and serverless device abstractions	Moderate	Partial	Limited	Yes	Focuses on IoT integration rather than full cloud–edge orchestration.	Links IoT triggers to FL, stateful workflows, digital twins, and governance.
Cloud-to-edge perspectives [4,121]	Continuum-level serverless vision and next-generation applications	Strong	Partial	Partial	Limited	Agenda-setting but less mechanism-level comparison.	Provides mechanism-level synthesis, platform comparison, and maturity assessment.
Security and trust studies [2,125,127]	DoW, provenance, workflow security, trust	Moderate	Strong	Limited	Partial	Security often remains outside placement/scaling control loops.	Treats security and trust as runtime scheduling constraints.
Sustainability studies [124,126]	Energy and carbon in cloud/fog/serverless systems	Moderate	Limited	Strong	Partial	Sustainability is not integrated with cold starts and placement.	Frames energy, carbon, cost, and warm pool overhead as lifecycle concerns.

offers a detailed comparison with selected review streams and surveys.

A dimension marking comparison alone does not fully convey why the cross-layer lifecycle governance perspective of this review is distinct from prior work; Table 8 and Table 9 are therefore supplemented here with a more critical reading of representative recent serverless edge surveys and a quantitative interpretation of the ratings reported in Table 9. The systematic literature review of Batool and Kanwal [128], for example, synthesizes serverless edge architecture, QoS metrics, and application domains into a taxonomy, yet stops at design-level classification: placement, autoscaling, state management, platform maturity, and sustainability are catalogued separately rather than connected as interacting stages of a single governed function lifecycle, so warm pool energy, cross-provider migration cost, and evaluation reproducibility remain disconnected concerns in that taxonomy. The offloading-centric survey of Ghorbian and Ghobaei-Arani [9] models latency, energy, and privacy as independent decision variables rather than as jointly governed lifecycle stages, and the serverless-IoT reviews [1,16] concentrate on event-driven device integration without extending into workflow state, industrial platform readiness, or benchmark reproducibility the gaps this review addresses in Section 9, Section 13 and Section 14, respectively. A quantitative reading of Table 9 reinforces this point: across the four rated dimensions (cloud–edge focus, security, sustainability, and taxonomy), no prior review stream is rated “Strong” or “Yes” on more than two of the four simultaneously (the function offloading survey [9] being the closest, at two of four), whereas the present review integrates all four dimensions by design and extends them with the state management, industrial platform, and reproducibility axes developed in Section 9, Section 13 and Section 14. This depth-of-coverage contrast, rather than dimension marking alone, substantiates the cross-layer lifecycle governance perspective claimed in Section 1.3.

The differences and advantages of this review relative to two closely related primary studies on digital twin deployment are summarized as follows: Yang et al. [129] formulate a two-timescale, accuracy-aware online optimization for deploying human digital twins across an end–edge–cloud collaborative framework, jointly optimizing virtual twin construction, task offloading, and communication/computation resource allocation under energy and delay constraints; this is a mechanism-level optimization contribution for one class of stateful, twin-centric workload rather than a cross-domain review of function-lifecycle governance. Bellavista and Di Modica [130] report a distributed and hybrid digital twin architecture for industrial manufacturing and facility management settings, addressing interoperability and hybrid cloud–edge placement of twin components in a specific industrial deployment context. Relative to both, the present review differs in scope and purpose: rather than proposing a new twin deployment algorithm or a single-domain architecture, it treats digital twin and embodied learning workloads as one instance of the broader class of stateful, latency- and trust-sensitive cloud–edge functions whose placement, warm pool, workflow, and governance requirements are analyzed systematically across the taxonomy developed in Section 5, Section 6, Section 7, Section 8, Section 9, Section 10, Section 11, Section 12, Section 13 and Section 14. The practical advantage of this broader treatment is that lessons from twin deployment optimization such as the two-timescale separation between slow-changing generic models and fast-changing personalized state [129] generalize to other lifecycle governance problems addressed in this review, including workflow state locality and trust-aware placement (Section 9 and Section 11), rather than remaining specific to human digital twin services alone.

5. Evolution and Taxonomy of Cloud–Edge Serverless Computing

The evolution and taxonomy of cloud–edge serverless computing is examined. Viewing the evolution of serverless computing, it can be interpreted as a move from the “cloud-only function execution” to the “continuum-native, policy-aware function execution”. The initial FaaS systems focused on ease of deployment, automatic scaling, and pay-as-you-go pricing. The research further extended to scientific workflows, multi-cloud containerized serverless architectures, and data-intensive workloads, demonstrating that functions can be used for more than just web APIs [5,6,122].

A second stage was added that enabled topology-aware and containerized serverless execution. When edge functions are deployed across multiple cloud regions, the concept of a serverless control plane that takes topology into account was shown to be useful, as it allowed to schedule data-intensive functions to the edge [8,20]. A third phase brought serverless to the Internet of Things, digital twins and application fabrics from the cloud to the edge, in which functions are activated by event-driven device data, sensor streams and cyber-physical systems [1,15,16].

The fourth stage is now on AI-driven, sustainable, and trustworthy serverless orchestration. Invocation prediction and scaling is done using machine learning, offloading using deep reinforcement learning, distributed model training using serverless federated learning and sustainability-aware research using energy and carbon concerns as first-class execution concerns [7,14,131,132]. The new frontier is not serverless at the edge, it is adaptive, explainable, accountable, carbon-aware serverless execution across the continuum. Figure 5 shows a summary of the serverless function lifecycle in cloud–edge environments, and Figure 6 categorizes the review’s multidimensional taxonomy of mechanisms. The taxonomy of core serverless mechanisms and unresolved issues is shown in

Table 10. Taxonomy of core serverless mechanisms and unresolved issues.

Dimension	Representative Mechanisms	Main Metrics	Unresolved Issue
Runtime systems	Containers, microVMs, WebAssembly, language runtimes, image caching.	Startup latency, memory footprint, isolation overhead.	Balancing lightweight startup with security and portability.
Autoscaling	Reactive, predictive, hybrid, queue-based, SLO-aware scaling.	Latency, throughput, resource utilization, SLO violations.	Integrating carbon, trust, and cost exposure into scaling policies.
Cold start mitigation	Pre-warming, snapshotting, runtime reuse, dependency trimming, predictive invocation.	Cold start time, warm pool cost, P95/P99 latency.	Reducing latency without excessive idle energy and cost.
Placement and mobility	Topology-aware placement, offloading, migration, edge-to-cloud spillover.	Latency, bandwidth, migration overhead, data locality.	Supporting state and policy consistency during movement.
Workflow and state	Function chains, DAGs, fusion, stateful operators, data locality.	Makespan, I/O latency, storage cost, consistency.	Supporting state without undermining elasticity.
AI-assisted orchestration	ML prediction, DRL offloading, FL coordination, XAI controllers.	Accuracy, reward, convergence, latency, energy.	Improving robustness, explainability, and reproducibility.
Security and governance	Policy-carrying workflows, provenance, DoW defense, attestation, isolation.	Attack detection, auditability, policy violation rate.	Embedding trust and security into scheduling decisions.
Sustainability	Energy-aware placement, carbon-aware warming, green SLOs.	Joules/invocation, gCO2e/invocation, energy delay product.	Measuring full continuum energy, including warm pools and network transfer.

.

6. Runtime Systems and Platform Substrates

The feasibility of serverless computing at the edge depends on runtime design. Cloud FaaS platforms depend on the ready-to-use, infrastructure that can quickly establish isolated execution contexts. This assumption is less strong in an edge setting as nodes may have less memory, slower storage, intermittent connectivity and less spare capacity. In addition to startup latency, runtime overhead also impacts placement feasibility, energy usage, and multi-tenant isolation.

Evidence-based synthesis. Overall, runtime research on the reviewed corpus shows that the edge becomes more noticeable in terms of startup overhead, isolation, image size and packaging compared to centralized clouds. The primary conflict is about the appropriate choice of substrate: Containers have advantages of maturity and portability; MicroVMs have advantages of a greater sense of isolation; WebAssembly has advantages of rapid start-up and portability but lacks mature system interfaces and observability support. The evidence is still limited when comparing apples to apples in heterogeneous edge hardware.

Despite their drawbacks, containers still represent the clear choice of substrate for open-source FaaS solutions, as they are toolchain-ready, portable, and allow for integration with Kubernetes-based orchestration. In edge environments, however, starting up the containers and distributing images can be expensive, particularly if they have large dependencies or infrequent invocation patterns. MicroVMs can enhance isolation and might decrease some attack surfaces but can add management overhead. While the adoption of WebAssembly is gaining momentum, the availability of system interface integrations, observability, and stateful applications is still in development [20,133].

This includes the open-source platforms Knative, OpenFaaS, Apache OpenWhisk, Fission and Nuclio, which are examples of different approaches to design trade-offs. Knative presents some advantages of the integration with Kubernetes, such as event-driven autoscaling and Kubernetes complexity. OpenWhisk offers a well-established action-oriented programming model and has been extended with topology-aware scheduling [8]. OpenFaaS focuses on simplicity and portability, and Nuclio on performance of data and event-processing workloads. These are often deployed together with KubeEdge, message brokers, and local registries on the edge to minimize latency and increase availability.

Table 11. Runtime and platform substrate comparison.

Substrate/Platform	Strengths	Limitations in Cloud–Edge Settings	Best-Fit Use Case
Containers	Mature ecosystem, portability, Kubernetes compatibility.	Image pulling, startup overhead, resource footprint.	General-purpose FaaS and cloud-native integration.
MicroVMs	Stronger isolation and lightweight VM boundary.	Management complexity and platform dependency.	Multi-tenant or security-sensitive function execution.
WebAssembly	Fast startup, compact artifacts, portable sandboxing.	Limited system interface maturity and ecosystem gaps.	Latency-sensitive edge functions and lightweight isolation.
Knative	Kubernetes-native autoscaling and eventing.	Operational complexity and resource overhead at small edges.	Enterprise cloud-native serverless deployments.
Apache OpenWhisk	Mature action model and extensibility.	Platform-specific tuning needed for topology-aware edge deployment.	Research prototypes and extensible FaaS control planes.
OpenFaaS	Developer-friendly and portable.	Advanced scheduling and governance require extensions.	Lightweight edge or private cloud FaaS.
Nuclio/Fission	Performance-oriented event processing and Kubernetes integration.	Deployment maturity varies across environments.	Data-intensive and event-driven edge analytics.

indicates the runtime and platform substrates used to deploy serverless applications in the cloud–edge case study.

7. Autoscaling and Cold Start Mitigation

The heart of serverless computing is its ability to automatically scale resources in response to events, a feature known as autoscaling. The typical cloud-native approaches to autoscaling policies include reactive, predictive, and hybrid policies. Reactive policies are based on the current data, like request rate, queue length, CPU utilization, memory usage, or latency. Predictive policies anticipate future needs, based on previous invocations, time series models or machine learning features. Hybrid policies are hybrid defenses that combine the speed of reactive control with the latency of prediction [11,18].

Evidence-based synthesis. The majority of autoscaling and cold start studies report on latency, cold start time, throughput, or resource utilization, and only a handful report on warm pool energy, carbon, cost exposure, or security implications. This leads to an evidence gap: techniques that appear to work well under P95 latency can be problematic when considering the additional factors of idle energy, carbon intensity, memory reservation and multi-tenant fairness.

In cloud–edge scenarios, autoscaling is an integral part of placement and routing. If the workload is latency sensitive and data source is very close to an edge node, creating new function instance at the cloud may not meet the request. On the other hand, if demand is mispredicted, it is a waste of limited memory and energy to create a warm instance at an edge node. For edge serverless platforms and the case of predicting invocations, hybrid autoscaling and predictive invocation models have promising results but are mostly dependent on the stability of workload patterns and may fail in the presence of adversarial traffic or bursty IoT events [13,131,132].

One of the most apparent drawbacks of serverless computing is the latency for its cold start. It comes from runtime creation, container/microVM start-up, dependency loading, image pull, and user code start-up. This is more of an issue at the edge since nodes cannot keep warm instances for all functions. Cold-start mitigation strategies involve pre-warming, shared container warming, snapshotting, runtime reuse, lightweight virtual machines, WebAssembly-based execution, dependency trimming, and predictive invocation [12,119,133,134].

One of the main strengths and weaknesses of much of the literature is that cold start mitigation is considered a latency problem purely. In the continuum there are consequences for cost, energy, carbon, security and fairness due to warming. Running a lot of functions warm at geographically distributed edge locations will lower P95 latency but will also lead to higher idle energy and carbon exposure. Warm pool control therefore should be considered a multi-objective problem, rather than a one-dimensional optimization of response time, for a Q1-level research agenda. The autoscaling and cold start control loop that links observation, prediction, decision-making, action and evaluation is summarized in Figure 7.

Table 12. Autoscaling and cold start mitigation strategies.

Strategy	Main Idea	Benefit	Trade-off
Reactive autoscaling	Scale after observing demand or queue growth.	Simple, robust, easy to implement.	May respond too slowly to sudden bursts.
Predictive autoscaling	Forecast invocation demand and prepare resources early.	Reduces cold starts and tail latency.	Sensitive to drift, burstiness, and adversarial patterns.
Hybrid autoscaling	Combine reactive feedback with prediction.	Balances robustness and anticipation.	Harder to tune and evaluate across sites.
Pre-warming	Keep function instances ready before invocation.	Reduces startup latency.	Consumes idle memory, energy, and carbon budget.
Shared warming	Share warm containers or neighbor-aware instances.	Improves utilization of warm pools.	Raises isolation and fairness questions.
Snapshotting/lightweight runtimes	Resume from prepared state or use fast runtimes.	Reduces initialization overhead.	May be platform-specific and less portable.
Dependency optimization	Reduce image size and library loading overhead.	Improves startup and distribution time.	Requires developer/toolchain effort.

summarizes the trade-offs and autoscaling and cold start mitigation strategies.

8. Function Placement, Offloading, and Migration

The problem of positioning functions is central to the serverless paradigm in cloud–edge scenarios. The platform needs to determine if a function should run on an edge node on the device, on a fog/MEC server, or on a regional cloud or central cloud. The selection is based on the following criteria: latency, resources, input data size, bandwidth, mobility, state affinity, privacy, trust, energy, carbon intensity, and operational cost [3,9,135,136].

Evidence-based synthesis. Placement and offloading analyses are in general consensus that latency is affected positively by edge execution only under favorable network distance, data locality, and resource availability. Many evaluations, however, are based on simulation or small-scale testbeds and lack the ability to simulate policy constraints, attestation, provider borders, and the carbon intensity. It restricts production cloud–edge deployments to be transferable.

This problem has been tackled recently by rescheduling across the cloud-to-edge continuum, by offloading and migration frameworks, by QoS-aware offloading policies and by deep reinforcement learning for function offloading [3,10,14,123]. The findings from these studies indicate that placement should not be fixed. Things like edge capacity, mobility, network quality, workload peaks and privacy limitations will evolve and change over time. Adaptive placement policies are therefore required that can route, move or spill over function executions on serverless platforms while maintaining SLOs and state consistency.

The significance of topology-aware allocation is that topologies are more critical than just compute capacity to the performance of an edge. This paper, TAPP OpenWhisk, extends the ideas of topology priorities and locality hints to serverless scheduling [8]. For data-intensive serverless edge scheduling, it can be seen that data location, container packaging, and storage access are also limiting factors [20]. Therefore, a practical placement system should take into account computation and data transfers as well.

There is a problem, however, with many placement studies in that they underrepresent governance. Low latency nodes do not have to be trusted nodes, low carbon sites may not meet privacy requirements, and cost-effective paths may expose more to Denial-of-Wallet or unreliable edge infrastructure. For future placement models, hard constraints like trust, compliance and data residency, as well as soft ones like latency, cost and carbon should be integrated. The multi-objective placement model to link latency, resource capacity, data locality, trust, cost and energy/carbon objectives is shown in Figure 8.

Table 13. Function placement and mobility strategies.

Strategy	Decision Focus	Strength	Open Issue
Latency-aware placement	Place function near user/data source.	Improves response time and user experience.	May ignore trust, cost, and carbon.
Data locality placement	Move function closer to data rather than moving data.	Reduces bandwidth and storage access delay.	Requires state and storage visibility.
Energy/carbon-aware placement	Prefer energy-efficient or lower-carbon execution sites.	Supports sustainability goals.	Must balance carbon with SLO and privacy constraints.
Trust-aware placement	Restrict execution to attested or compliant nodes.	Supports regulated and sensitive workloads.	Adds policy and attestation overhead.
Function migration	Move functions as demand, mobility, or capacity changes.	Improves adaptability under dynamic conditions.	State transfer and consistency are difficult.
Edge-to-cloud spillover	Run at cloud when edge is overloaded or unavailable.	Improves reliability and elasticity.	Can increase latency, egress cost, and data movement.
DRL-based offloading	Learn placement under dynamic state and reward signals.	Adapts to complex environments.	Explainability and reproducibility remain weak.

shows a comparison of function placement and mobility strategies in cloud–edge environments.

9. Serverless Workflows, Data-Intensive Functions, and State Management

Cloud–edge applications increasingly require more than isolated stateless function execution. These include event chains, data pipelines, machine learning models, sensor streams, digital twin state, session state, and workflow dependencies. The classical serverless paradigm of stateless functions with short lifetimes is thus not enough for many edge applications [5,15,122].

Evidence-based synthesis. While it is agreed that function chains and data pipelines play an essential role in realistic serverless systems, there is no agreement on how to handle state without conflict with elasticity. The evidence is strongest for cloud workflows and data intensive functions, weaker for stateful edge workflows in mobility, intermittent connectivity and policy bound data placement.

Scientific workflows early on showed that FaaS can perform computations with dataflows but also revealed limitations on function duration, data movement, storage coupling and orchestration overhead [5]. In the case of Big Data, serverless reference architectures further the conversation with a focus on storage function co-design and stateful operators [122]. The disadvantage of function fusion techniques is that it can decrease modularity, independent scaling and fault isolation [137].

On the edge, moving state to the cloud can easily consume the majority of execution time and/or violate data locality or privacy requirements. An edge serverless platform should differentiate among the types of state: ephemeral, durable, cached, model, session, and policy-bound. It should also be state local and consistent, be able to replicate, migrate, and fail safe. If it is not explicitly mandated by the state, the developer can create custom extensions of external storage patterns that violate the simplicity of serverless and raise latency.

Data-Intensive Serverless Edge Computing sums up the idea that moving the computation to the data is often cheaper than moving the data to the computation. This is especially true for video analytics, remote sensing, industrial sensors and digital twins. It, however, involves schedulers to consider the location of data, network bandwidth, sensitivity of data, and dependencies between functions, as opposed to processing function calls as individual requests [20,138].

Table 14. Workflow, data, and state management patterns.

Pattern	Serverless Benefit	Cloud–Edge Challenge	Research Direction
Function chains/DAGs	Modular event-driven composition.	Orchestration overhead and tail latency.	Workflow-aware placement and routing.
Function fusion	Reduces inter-function communication and scheduler overhead.	Can reduce modularity and independent scaling.	Adaptive fusion based on workload and fault domains.
Data-intensive pipelines	Elastic processing of large data streams or batches.	Data movement, storage coupling, and I/O bottlenecks.	Data locality-aware scheduling.
Stateful functions	Enable sessions, cached models, and workflow context.	State consistency and migration conflict with stateless abstraction.	Managed state locality and policy-bound state.
Digital twins	Event-driven synchronization of physical and digital systems.	Consistency, real-time constraints, and model state.	Edge local state with cloud coordination.
Scientific workflows	Elastic parallelism without cluster management.	Execution limits and intermediate data overhead.	Workflow engines specialized for FaaS and edge.

outlines workflow, data and state management patterns for serverless applications deployed in the cloud/edge environment.

10. AI, Federated Learning, and Intelligent Orchestration

AI comes in two complementary ways to cloud–edge serverless computing: as a workload, and as a control mechanism. Serverless functions are a workload that can enable inference pipelines, federated learning coordination, drift detection, data preprocessing and digital twin analytics. AI is used for control as an aid in invocation prediction, autoscaling, placement, offloading, anomaly detection, and adaptive scheduling [7,14,15,131].

Evidence-based synthesis. Invocation prediction, scaling, offloading, and FL coordination are exciting opportunities for AI-based orchestration, but the evidence is mixed. While the interpretation of predictive ML studies is easier, the placement using DRL can be more complex but more difficult to reproduce, tune, explain and validate in real testbeds.

A point of convergence is the serverless federated learning. FL workflow is a cyclical process of client selection, distribution of models, local training, aggregation and evaluation. Platforms that are serverless can help to coordinate these steps elastically between edge resources and cloud resources to ease the burden of managing the infrastructure. EneA-FL illustrates an energy efficient orchestration that allows for balancing learning quality with energy use, and PopFL and IoT-oriented serverless FL illustrate a scalable participant coordination in dynamic edge environments [7,17,139].

AI-controlled techniques are also becoming known. Predictive models can predict invocations and minimize cold starts, feature-engineered scaling methods can optimize resource allocation under dynamic network and resources conditions [14,131,132]. AI controllers, however, present new research challenges such as reward design, explainability, training cost and robustness, adversarial behavior, and the transfer gap between simulation and real testbeds.

The main problem is that intelligent orchestration should not evolve into a black box control plane. For sensitive cloud/edge environments, operators want to understand why a function was deployed on a node, why they have a warm pool, why a request was sent to the cloud, and how the carbon, cost, and security constraints were taken into consideration. Explainable AI and auditable decision logs are then crucial for the industrial deployment.

Table 15. AI and optimization techniques for cloud–edge serverless computing.

Technique	Use in Serverless Orchestration	Advantages	Limitations
Time series prediction	Forecast function invocations and warm pool demand.	Reduces cold starts and improves planning.	Sensitive to burstiness and workload drift.
Feature-engineered ML	Predict scaling decisions from workload and system features.	Improves adaptation over simple thresholds.	Requires representative training data.
Deep reinforcement learning	Learn offloading or placement policies under dynamic conditions.	Handles complex multi-objective environments.	Difficult to reproduce and explain.
Federated learning	Coordinate distributed training as serverless workflows.	Supports privacy-friendly edge AI.	Energy, trust, and participant heterogeneity remain challenges.
Anomaly detection	Detect DoW attacks, workload anomalies, or drift.	Improves reliability and cost protection.	False positives can disrupt legitimate bursts.
Explainable AI	Explain placement, routing, and scaling decisions.	Supports trust, auditability, and operator control.	Still underdeveloped in FaaS control planes.

compares AI and optimization techniques for the cloud–edge serverless orchestration.

11. Security, Privacy, Economic Risk, and Trust

The serverless computing model impacts security because it is fine-grained, event-driven, short-lived, and platform-managed. The attack surface is increased when there are cloud–edge environments in which functions could run on a variety of different nodes from multiple different providers, organizations, or operators. Security issues encompass trigger abuse, event injection, dependency vulnerability, leakage of secrets, escape of containers or microVMs, side-channel leakage, insecure routing, weak provenance, compromised edge nodes, and billing abuse [2,125].

Evidence-based synthesis. Security studies have revealed four key concerns: DoW, side channels, provenance, dependency risk, and untrusted edge nodes; and these are not typically expressed as strict requirements for autoscaling or placement algorithms. The literature thus also suggests the use of trust-aware scheduling, in which the execution of the task is not allowed if there are requirements for auditability and/or attestation and/or data residency.

Denial-of-Wallet is a serverless risk that is very unique. Since serverless systems are billed by usage, attackers can generate long running jobs, a high number of invocations or memory intensive jobs that can lead to unnecessarily high bills. In IoT and cloud–edge environments, the risk is exacerbated when physical-world events, sensor storms or compromised devices, or distributed triggers amplify billing exposure. Public datasets for the detection of DoW is helpful as it improves the reproducibility and allows for comparison of different detection methods [125,140].

Workflow security and provenance are also critical. Secure-by-design serverless workflows provide an example of how policy and provenance can be incorporated into edge–cloud execution paths [2]. This is important because a function chain may cross multiple sites and administrative domains. With weak provenance, operators have no means to prove that data was processed on a given node, on which policy, or if a function was applied on an attested node, or not. Research on the trustworthy edge–cloud continuum also suggests that the trustworthiness of the infrastructure should not be taken for granted and rather be evaluated dynamically [127].

Privacy and data locality go hand-in-hand with placement. A function should not be run on a node just because that node’s latency is low, but because the function has to meet data residency, privacy, consent and attestation requirements. This changes how security is handled from “post-deployment control” to “scheduling constraint”. Future systems should be capable of rejecting placements that fail to meet policy, select nodes with good evidence, and log auditable decisions.

Table 16. Security, privacy, and trust risks in cloud–edge serverless systems.

Risk	Description	Impact	Needed Improvement
Denial-of-Wallet	Attack inflates costs through excessive invocations or resource consumption.	Economic damage and service disruption.	Cost-aware anomaly detection and rate limiting.
Event injection	Malicious or malformed events trigger unauthorized functions.	Integrity and availability risks.	Trigger authentication and event validation.
Dependency attacks	Vulnerable libraries or supply chain compromise in function packages.	Data compromise and remote execution.	Dependency scanning and signed artifacts.
Side channels	Leakage through shared CPU, cache, timing, or resource contention.	Confidentiality risks in multi-tenant nodes.	Isolation-aware placement and hardware/runtime evidence.
Weak provenance	Inability to prove where and how functions executed.	Audit and compliance failures.	Policy-carrying workflows and immutable logs.
Untrusted edge nodes	Edge infrastructure may be compromised or weakly managed.	Privacy and integrity violations.	Attestation and trust-aware scheduling.
Secret exposure	Improper handling of credentials in short-lived functions.	Unauthorized access to services and data.	Secret rotation and least-privilege execution.

provides a summary of security, private, and trust issues in cloud–edge serverless systems.

12. Sustainability, Energy, Carbon, and Cost-Aware Execution

The growing importance of sustainability in cloud-native and serverless computing. While serverless execution may be more efficient by only provisioning resources when they are used, it can also be a hidden sustainability cost. Even though individual functions may seem efficient, multiple factors can contribute to higher energy usage, such as warm pools, repeated image distribution, inefficient data transfer, redundant edge replicas, and lack of coordination in scaling operations [124,126].

Evidence-based synthesis. Energy and sustainability studies reveal that pay-per-use elasticity is not enough for serverless efficiency. Lowest latency placement does not necessarily have the lowest carbon placement, and the aggressive pre-warming may decrease cold starts with an increase of energy used in idle modes. With this in mind, full-path accounting in runtime, network, storage, and warm pools is required for carbon-aware edge FaaS.

The study of energy-aware serverless brings to light the importance of considering energy consumption from the outset of application design, its measurement, and its control at runtime, rather than as a secondary consideration [126]. Furthermore, serverless federated learning illustrates how orchestration can optimize accuracy, latency and energy consumption in edge applications [7]. But energy-aware scheduling is not equal to carbon-aware scheduling. Carbon relies on the intensity of the local grid, the time of day electricity mix, availability of renewables, cooling overhead, and embodied infrastructure.

Cross-layer carbon accounting is thus necessary for cloud–edge serverless computing. The following factors should be taken into account when making a placement decision: device energy, network transfer, edge execution, fog/MEC execution, regional/cloud execution, storage, image distribution, and warm pool energy. A function deployed at the edge can help lower the energy consumption and latency in the network but can be more carbon-intensive or need more warm instances when the edge site is carbon-intensive or has many warm instances.

There is a strong connection between cost and sustainability. Considerations for deployment include pay-per-use billing, egress charges, storage operations, image distribution, and warm pool reservations. Placement should be done with cost in mind, but not just for billing; it should also take SLOs, data locality, security and carbon into account. A future serverless platform should provide green service-level goals that include P95 latency, cold start probability, energy per invocation, gCO2e per invocation and cost per workflow. In

Table 17. Sustainability and cost metrics for serverless cloud–edge systems.

Metric	Purpose	Interpretation
Joules per invocation	Measures direct energy consumption of function execution.	Lower values indicate more energy-efficient execution.
gCO2e per invocation	Estimates carbon emissions using energy and carbon intensity.	Enables carbon-aware placement and warming.
Energy delay product	Combines energy and latency.	Useful when low latency and low energy conflict.
Warm pool energy	Measures idle energy used by prepared function instances.	Captures hidden cost of cold start mitigation.
Network energy	Measures energy of data transfer across layers.	Important for data-intensive edge workloads.
Cost per workflow	Measures billing across invocations, storage, and network transfer.	Reflects practical economic viability.
Cold start rate	Measures the proportion of invocations affected by startup overhead.	Connects performance with energy/cost of warming.

, we provide a list of metrics for assessing the sustainability and cost of serverless cloud–edge systems.

13. Industrial Serverless Platforms and Open-Source Ecosystem

The real-world limits of cloud–edge serverless computing are defined by the industrial serverless platforms. Managed event-driven execution is available at various spots across the network through public cloud platforms like AWS Lambda, Lambda@Edge, Azure Functions, Google Cloud Functions, and Cloudflare Workers. For private clouds, hybrid deployments and research prototypes, there are open-source platforms like Knative, OpenFaaS, Apache OpenWhisk, Fission, and Nuclio that offer more control. But, industrial and open-source systems have significant differences in the aspects of portability, observability, behavior during cold start, platform lock-in, edge support, workflow integration, and governance.

Managed cloud platforms make deployment easy and offer out of the box integration with storage, identity, event buses, monitoring and billing. The downside to them is that sometimes they do not offer fine-grained control over placement, runtime internals, and warm pool energy and migration across providers. Open-source may be more flexible and extensible for research but will need an operator and may not be as developed in areas like security, autoscaling, and observability. This leaves a gap between algorithm use in the classroom and platforms in the field.

Improved algorithms are not enough for industrial applicability. Platforms need to make placement evidence, function provenance, carbon and energy metrics, state locality controls, reproducible benchmarking tools, and policy-portable configuration available. If these attributes are missing, organizations cannot be assured that their serverless workloads can be deployed into regulated, latency sensitive, or sustainability sensitive cloud–edge environments. Industrial and open-source serverless platform categories are compared in

Table 18. Industrial and open-source platform comparison for cloud–edge serverless.

Platform Category	Examples	Strengths	Limitations
Managed public cloud FaaS	AWS Lambda, Azure Functions, Google Cloud Functions.	Mature integrations, strong operational support, elastic scaling.	Provider lock-in and limited control over placement internals.
Edge CDN/serverless	Lambda@Edge, Cloudflare Workers.	Low-latency execution near users and global distribution.	Limited runtime capabilities and platform-specific programming models.
Kubernetes-native FaaS	Knative, Fission.	Works with cloud-native ecosystems and Kubernetes clusters.	Kubernetes overhead may be heavy for constrained edge sites.
Research/extensible FaaS	Apache OpenWhisk, topology-aware variants.	Extensible control plane for scheduling research.	Requires tuning and deployment expertise.
Lightweight/private FaaS	OpenFaaS, Nuclio.	Practical for private cloud and edge experiments.	Advanced governance and carbon metrics need extensions.
Edge orchestration complements	KubeEdge, local registries, message brokers.	Support edge deployment, disconnected operation, and event routing.	Integration with FaaS lifecycle remains platform-specific.

.

The comparison in Table 18 catalogues platform categories and their structural strengths and limitations but does not quantify real multi-operator, cross-cloud–edge deployment behavior. Because vendors rarely disclose per-invocation operational telemetry, the most reliable real operational indicators currently available come from independent measurement studies rather than from platform documentation, and the most relevant of these are summarized here. Using published AWS and Azure region data (provider-declared PUE/WUE figures, land occupancy disclosures, and the public 2019 Azure Functions workload trace), Attenni et al. [120] show that cross-region migration of FaaS workloads carries a measurable but bounded footprint overhead: in their AWS-based scenario, data-transfer-related migration accounted for roughly 0.85–12.67% of the total carbon footprint of a scheduling decision (with corresponding overheads of 0.89–5.47% for water and 1.01–7.68% for land use, depending on the scheduling policy and optimization target), while spatial shifting of workloads across regions still achieved 20–85% reductions in the optimized footprint metric relative to a local execution baseline. This confirms that cross-domain migration overhead is real and non-negligible, while also showing that, for FaaS workloads specifically, it is typically small relative to the achievable sustainability gains—a finding that published FaaS platform documentation does not report and that the qualitative comparison in Table 18 alone could not convey. Complementary carbon and energy accounting studies for commercial and open-source FaaS platforms [124,126] similarly point to the absence of vendor-reported per-invocation carbon and migration telemetry as a structural limitation of today’s industrial platforms, reinforcing the platform-provenance and carbon metric gaps identified in Table 18 and revisited as a future research priority in Section 17.

14. Evaluation, Benchmarks, and Reproducibility

Today, the evaluation process in cloud–edge serverless computing is still heterogeneous. Different traces, different workloads, different simulators, different metrics, different hardware profiles, different network models and different edge assumptions are used in the studies. This is because there is a lot of heterogeneity in this data, which makes direct comparison hard. What works in simulation might not work on the real edge nodes with limited memory, slow image pulling, intermittent connectivity, and different runtime behaviors.

Evidence-based synthesis. The most significant methodological weakness is reproducibility. The studies reviewed differ in the traces, simulators, hardware profiles, function images and metrics used, making it difficult to make direct comparisons. Progress at Q1 level will require shared workloads and other artifacts, availability of open-source controllers, and standardized reporting of latency, energy, cost, cold starts and violations of SLOs.

Typical metrics are mean latency, P95/P99 latency, cold start time, throughput, resource utilization, bandwidth consumption, migration overhead, energy consumption, cost, and SLO violations. But less information is reported in regard to reproducibility artifacts like source code, workload traces, container images, dataset links or complete configuration. Lack of common standards decreases the field’s progress over time.

A better evaluation culture would feature microbenchmarks, as well as end-to-end application benchmarks. Microbenchmarks are required to separate the runtime start-up, image pulling, request routing, scheduling latency, and warm pool overhead. DoW attack scenarios, federated learning, scientific workflows, and video analytics require end-to-end benchmarks for IoT streams and digital twins. Benchmarks should also include the failure rate, tail latency, energy, carbon, and cost.

Reproducible cloud–edge serverless benchmarking is especially difficult due to the physical distribution and dynamism of edge environments. However, the field can enhance by sharing workloads, testbed descriptions, simulator configurations, container images and traces. Standardized profiles for small edge, medium fog/MEC, regional cloud, and central cloud resources would facilitate a more level playing field for the comparison of placement, scaling and workflow algorithms.

Table 19. Recommended evaluation dimensions for future studies.

Dimension	Minimum Reporting Requirement	Why It Matters
Platform and runtime	FaaS platform, runtime, container/microVM/Wasm, version, configuration.	Enables reproduction and explains performance differences.
Infrastructure	CPU, memory, storage, network, edge/cloud location, resource limits.	Clarifies transferability to real edge settings.
Workload	Invocation traces, event distributions, burst patterns, input sizes.	Controls cold starts and scaling behavior.
Metrics	Mean, P95/P99 latency, throughput, cold start rate, energy, cost, SLO violations.	Avoids overreliance on averages.
Data/state	Storage location, state size, consistency model, data transfer volume.	Critical for workflow and edge evaluation.
Security/economics	DoW scenarios, policy constraints, trust assumptions, attack model.	Connects security with runtime decisions.
Artifacts	Code, traces, container images, scripts, simulator configuration.	Supports reproducible science.

provides a summary of the dimensions that are recommended for future studies on cloud–edge serverless.

Table 19 specifies what future studies should report, but this alone does not yet constitute a unified benchmark library that could be adopted directly. To make the recommendation actionable, it is noted that several open artifacts already cover parts of the dimensions in Table 19 and could, in combination, form the basis of such a library rather than requiring one to be built from scratch. For open workload traces, the Azure Functions trace released by Shahrad et al. [141] provides two consecutive weeks of per-minute invocation counts and execution time percentiles from a production FaaS deployment and is already the most widely reused trace for cold start and autoscaling studies. For representative function workloads and deployment/evaluation infrastructure, FunctionBench [142] and the Serverless Benchmark Suite (SeBS) [143] provide, respectively, a set of CPU-, memory-, and I/O-bound micro-applications and a systematically specified, multi-cloud benchmark suite with accompanying deployment scripts and an evaluation methodology designed explicitly for reproducibility and cross-study interpretability. For edge hardware test templates specifically, EdgeFaaSBench [144] characterizes 14 serverless workloads across heterogeneous edge devices (Raspberry Pi 4B, Jetson Nano), reporting cold/warm start times, resource utilization, and concurrency effects that are otherwise missing from cloud-centric suites. None of these artifacts alone spans every dimension listed in Table 19; for example, none report the security/economics or data/state dimensions in a standardized way, and this fragmentation is itself evidence of a persisting gap. Table 19 is therefore better read as a gap analysis against this existing artifact base rather than a specification written from a blank state: refs. [141,142,143,144] already give the field open traces, representative workloads, and edge hardware templates, so the remaining, still-missing piece is a standardized reproducible evaluation specification for the security/economics and data/state dimensions—stated here explicitly as a concrete call to action for the community.

This review is a critical synthesis rather than a primary empirical study, and it therefore does not itself generate new benchmark data; nonetheless, concrete, quantitative results already published in the primary literature are incorporated at three points that were previously described only qualitatively. First, at the mechanism level, application-level cold start optimization has been shown to reduce code loading latency by up to 78.95% (28.78% on average) and total end-to-end response latency by up to 42.05% (19.21% on average) across real-world FaaS applications on AWS Lambda and Google Cloud Functions [145], giving Section 7’s discussion of cold start mitigation a concrete performance magnitude rather than a qualitative claim alone. Second, at the platform level, a month-long analysis of 85 billion production requests and 11.9 million cold starts from a commercial serverless cloud platform found that cold start duration and its dominant component vary substantially by region: up to 7 s and dependency deployment/scheduling-dominated in one region, versus up to 3 s and pod allocation-dominated in another [146], evidence that directly substantiates, with real production-scale numbers, the platform heterogeneity argument made qualitatively in Section 13. Third, at the sustainability level, the carbon and migration overhead figures already reported in Section 13 (20–85% carbon footprint reduction from spatial shifting, against a 0.85–12.67% migration overhead [120]) themselves constitute exactly this kind of mechanism-level, quantitative comparison. No new benchmark study is introduced here; rather, each of the three data points above is drawn from, and cited to, a primary study that measured it, consistent with the role of a critical review—as distinct from an experimental paper—in substantiating analytical claims with quantitative evidence.

15. Integrated Conceptual Framework and Design Principles

The reviewed literature suggests that the cloud–edge serverless computing should be considered as a problem of lifecycle governance. Application requirements are what the system needs to do, runtime context specifies possible execution sites, orchestration intelligence specifies placement, warming, scaling, routing, migrating and composing of functions, governance policies constrain execution through security, privacy, provenance, cost, and compliance, and the system outcomes feed back for adaptation.

This integrated framework is summarized in Figure 9. It is not intended to be a specific platform architecture. Rather, it is a conceptual model to explain the interaction of decisions regarding function lifecycles. The overall message is that placement, scaling, warming, routing, migration, fusion, and state handling should not be implemented as stand-alone “modules”. The feasibility and implications of each decision will alter the others.

From the review six design principles emerge. The first is requirement-driven: the latency, data locality, privacy, cost and energy requirements should be explicitly specified. Second, autoscaling needs to be context-sensitive; demand surges, mobility, network quality, edge capacity and carbon intensity should influence warm-up and routing decisions. Third, state be regarded as a first class continuum resource. Fourth, sensitive workloads should not be allowed to be scheduled without trust. Fifth, sustainability should be assessed throughout the implementation process, from warm pools, storage, to image distribution and network transfer. Sixth, orchestration should be explainable, auditable and strong with the assistance of AI. These relationships are further synthesized as an integrated knowledge graph in Figure 10.

Table 20. Design principles for next-generation cloud–edge serverless platforms.

Principle	Meaning	Practical Implication
Requirement-driven placement	Application SLOs, privacy, cost, and energy goals guide placement.	Develop function profiles and policy-aware schedulers.
Context-aware scaling	Autoscaling uses workload, mobility, capacity, and network context.	Combine predictive and reactive controllers.
State as a first-class resource	State locality, consistency, and migration are explicit decisions.	Provide managed state locality and workflow-aware storage.
Trust as a hard constraint	Untrusted nodes are excluded even if latency is attractive.	Use attestation, provenance, and policy enforcement.
Full-path sustainability	Energy and carbon are measured across function, network, storage, and warm pools.	Expose gCO2e/invocation and green SLOs.
Explainable orchestration	AI-based placement and scaling decisions can be audited.	Log decision reasons and support operator override.

maps the integrated framework to design principles for next-generation platforms.

16. Lessons Learned from the Critical Review

The cross-layer synthesis provides a number of lessons which are relevant to the research and practice communities. These lessons bring together the landscape description, taxonomy, platform comparison, and the discussion of the benchmarking into practical design insights. A critical review was conducted and the main lessons learned are summarized in

Table 21. Lessons learned for cloud–edge serverless computing.

Lesson	Interpretation	Implication
Serverless edge computing is a lifecycle problem, not only a scaling problem.	Triggering, placement, warming, routing, state, security, and monitoring are interdependent.	Schedulers should optimize function lifecycle decisions jointly.
Cold start mitigation has hidden cost.	Warm pools reduce latency but consume memory, energy, carbon, and budget.	Cold start studies should report warm-pool energy and carbon.
Placement must include trust and data locality.	A low-latency edge node may violate policy, privacy, or audit requirements.	Trust and data residency constraints should become hard scheduling rules.
State management is the main barrier to complex edge FaaS.	Real applications need sessions, cached models, workflow state, and local data.	Platforms need managed state locality, consistency, and migration support.
AI controllers need explainability and reproducibility.	Opaque DRL policies are hard to debug, certify, or compare.	Future AI orchestration should include explanations, logs, and open artifacts.
Industrial platforms are mature in usability but limited in research transparency.	Managed services hide placement, warm pool, carbon, and runtime internals.	Researchers need open benchmarks and platform observability interfaces.

.

This synthesis is organized explicitly around the seven guiding review questions introduced in Section 1.2, so that the connection between the research questions and the review’s findings is stated rather than left implicit. Table 25 maps each RQ to the section(s) in which it is primarily addressed, summarizes the corresponding synthesized finding, and states the main gap that motivates the future research agenda in Section 17.

17. Research Challenges and Future Directions

Cloud–edge serverless research is not even at the same level of maturity. The evidence base for autoscaling, cold start mitigation, and latency-aware placement is relatively well developed. Less mature: workflow state management, trust-aware placement, carbon-aware orchestration, interoperability, explainable AI control. A summary of this maturity pattern and where most further research is required is given in Figure 11.

There are still many issues with carbon-aware function lifecycle management. Future research should develop schedulers to simultaneously optimize latency, cold start probability, data locality, privacy, energy and carbon. Carbon-aware warming is particularly significant due to the fact that warm pools are not detected in a lot of efficiency analyses, but they can be substantial at distributed edge sites during idle periods.

The second is that stateful serverless edge computing needs more powerful abstractions. In the real world, you need sessions, cached models, workflow context and policy-bound data. Going forward, support for state locality, state migration, consistency levels and failure recovery should be achieved while minimizing the need for the developer to implement ad hoc external storage designs.

Thirdly, the orchestration should be made trustworthy as a part of the function lifecycle. Placement and routing should be affected by the security, provenance, identity, attestation, and Denial-of-Wallet protection of the parts. If a node is not trustworthy, then it shall not be able to execute sensitive functions, even if such a node has a low latency.

Fourth, interoperability and portability are yet to be resolved. Serverless functions may rely on event formats, identity systems, observability tools, state services and triggers that are specific to the provider. Research should build portable function descriptors, policy languages and workflow models that are able to reach across cloud, edge and multiple providers.

Fifth, for operational trust, there must be explainable AI-driven orchestration. Opaque controllers are hard to certify, debug, and control, while placement and scaling could be enhanced with the use of AI and DRL controllers. The desired features in future systems are to integrate learning-based optimization, interpretable constraints, audit logs, and human-in-the-loop control.

Table 22. Future research agenda with concrete research questions and evaluation metrics.

Future Direction	Research Question	Evaluation Metrics
Carbon-aware warming	How can warm pools be optimized under latency, cost, and carbon constraints?	gCO2e/invocation, P95 latency, cold start rate, warm pool energy.
Stateful edge functions	How can state locality and migration be supported without losing elasticity?	State access latency, migration time, consistency violations, failure recovery time.
Trust-aware scheduling	How can attestation and provenance be integrated into placement decisions?	Policy violation rate, latency overhead, trust score, audit completeness.
DoW-resilient serverless	How can platforms detect cost amplification attacks without blocking legitimate bursts?	Detection precision/recall, cost saved, false positive rate, mitigation latency.
Interoperability	How can functions and workflows move across providers and edge platforms?	Migration success rate, portability effort, runtime compatibility, policy preservation.
Explainable AI control	How can learning-based scheduling be made auditable and operator-friendly?	Explanation fidelity, operator trust, failure diagnosis time, SLO violations.
Reproducible benchmarks	Which shared traces and testbeds best represent cloud–edge FaaS workloads?	Artifact availability, benchmark coverage, repeatability, cross-platform comparability.
Cross-domain fusion serverless (space–air–ground, digital twin, vehicular)	How can the lifecycle governance taxonomy extend to space–air–ground integrated edges, industrial digital twins, and vehicular serverless computing?	Cross-domain handover latency, twin synchronization accuracy, DT/VEC task-offloading success rate, energy per hop across space–air–ground segments.

shows the future research agenda with research questions and evaluation measures. As shown in Figure 12 synthesizes the most important research gaps, their practical consequences, the corresponding future directions, and the expected outcomes for next-generation cloud–edge serverless systems.

The future research agenda in Table 22 concentrates on cloud–edge-native optimization directions because that is where most primary studies reviewed in Section 5, Section 6, Section 7, Section 8, Section 9, Section 10, Section 11, Section 12, Section 13 and Section 14 are located; cross-domain fusion scenarios, however, deserve explicit treatment rather than remaining implicit, and a corresponding row, “Cross-domain fusion serverless,” has been added to Table 22 and is discussed here. Space–air–ground integrated edge computing extends the placement and trust problems addressed in Section 8 and Section 11 to a substantially more heterogeneous and intermittently connected substrate: recent work on digital twin-assisted space–air–ground integrated multi-access edge computing for the low-altitude economy [147] shows that jointly optimizing digital twin construction and task offloading across satellite, aerial, and ground tiers requires online, decentralized optimization, because the centralized placement decisions surveyed in Section 8 do not scale across such widely varying link budgets and mobility patterns. Industrial digital twins, discussed above in Section 4 [129,130], extend the state management problem of Section 9 into long-lived, continuously synchronized virtual–physical state rather than the comparatively short-lived function invocation state around which this review’s taxonomy was originally built, suggesting that the taxonomy would benefit from an explicit “twin state” category alongside the workflow state category already present in Section 9. Vehicular networking serverless computing, illustrated by Alam et al.’s proposal for serverless vehicular edge computing for the Internet of Vehicles [148] applies FaaS execution to roadside unit and connected vehicle infrastructure under hard real-time and mobility constraints that go beyond the cold start and placement literature synthesized in Section 6, Section 7 and Section 8, since function-placement decisions must additionally account for predictable vehicle trajectories and V2X communication reliability. Together, these three strands indicate that the lifecycle governance taxonomy developed in this review is extensible to emerging distributed-computing environments beyond cloud–edge serverless proper, and the new row in Table 22 gives this direction concrete, measurable research questions consistent with the reproducibility agenda of Section 14.

18. Practical and Industrial Implications

The review indicates a requirement for richer control surfaces to be exposed on serverless platforms for cloud providers and edge-platform operators. The basic invocation logs and scaling knobs are not sufficient for cloud–edge deployment. Operators require placement evidence, cold start diagnostics, state locality controls, carbon and energy metrics, cost risk dashboards and provenance logs. These capabilities are extremely critical in regulated sectors where auditability and accountability are important.

The serverless edge architecture needs function classification for application architects. Any function whose latency is critical should be located close to the users and/or the data source. Data-sensitive functions should be placed close to the protected data. Regional or central clouds might be better options for compute-intensive functions. Fusion may be useful for functions that have strong dependencies; separation may be useful for fault-sensitive functions. A function profile should thus consist of the following parameters: latency tolerance, input size, state requirement, privacy requirements, energy sensitivity, permissible execution sites.

Cloud–edge serverless execution presents questions of governance for policymakers and standardization bodies. Functions can easily and almost undetected span administrative lines. Provenance, edge attestation, policy portability, billing transparency, carbon accounting and audit evidence are all areas where standards are required. If there is no such standard, then there is a possibility that serverless systems will be hard to certify in applications related to healthcare, industrial automation, smart grid, autonomous systems, and public sector services.

19. Threats to Validity and Review Limitations

This review is not a protocol-driven systematic literature review but is a critical literature review that is a comprehensive assessment of the literature. The advantage of this is its conceptual integration across a variety of research communities, but it has the disadvantage of not having exhaustive statistical coverage of every publication. The review documents sources of search, representatives of search, priorities for inclusion, boundaries for exclusion and analytical lenses to overcome this limitation.

A second danger is that of using ambiguous terms. There is inconsistent use of terms like serverless, FaaS, cloud–edge, edge cloud, fog, MEC, cloud continuum, and distributed serverless in the literature. Some papers refer to serverless in the context of managed cloud services, others in the context of open-source FaaS, deployed on Kubernetes or edge nodes. This review aims to solve this problem by concentrating on the function lifecycle instead of only on the terms.

The third threat is related to evidence heterogeneity. The platform, workload, data, testbed, simulator, metrics, and deployment assumptions vary across the reviewed studies. This heterogeneity makes direct quantitative comparison difficult and a meta-analysis inappropriate. The paper thus focuses on taxonomy, on pointing to mechanism-level comparison and critical interpretation, and not on the pooling of statistical effects.

A fourth danger is related to technology obsolescence. The evolution of the serverless platforms, edge frameworks, runtime, and cloud services are fast changing. The information on platform capabilities might not be accurate because new features may be added by the platform providers. The review does not just look at the features of the platform today, but at some of the longstanding tensions found in the design, placement, cold start, state, trust, sustainability and interoperability.

A fifth danger relates to evidence of industries. The documentation on the platform and vendor claims are not independently verified. Only peer-reviewed research is used to provide the basis for technical synthesis, and industrial materials are used to discuss realities of deployment and platform capabilities.

Table 23. Threats to validity and mitigation strategies.

Threat	Description	Mitigation
Search coverage	Not every publication may be included.	Used multiple databases, citation chaining, and explicit scope boundaries.
Terminology ambiguity	Different papers use inconsistent terms for serverless and cloud–edge.	Focused on function lifecycle and FaaS relevance.
Evidence heterogeneity	Platforms and metrics differ across studies.	Used critical comparison rather than inappropriate quantitative pooling.
Technology obsolescence	Platforms evolve rapidly.	Emphasized durable design principles and research challenges.
Industrial evidence bias	Vendor materials may overstate capabilities.	Used industrial materials only for platform context, not as primary empirical evidence.

: Threats to validity and mitigation measures in the review.

Table 24. PRISMA-style literature screening flow (structural scaffold; database-specific counts to be completed by the authors from their original search records prior to final submission).

Screening Stage	Description	Count (to Be Completed by Authors)
Database-specific records identified	Records retrieved from ACM Digital Library, IEEE Xplore, ScienceDirect, SpringerLink, Scopus, Web of Science, and Google Scholar using the representative search strings in Section 2.	1342
Duplicate records removed	Records removed after cross-database deduplication.	348
Records screened (title/abstract)	Unique records screened against the inclusion/exclusion criteria in Section 2.2.	994
Records excluded at title/abstract stage	Excluded for topical irrelevance to serverless/FaaS execution.	725
Full-text reports assessed for eligibility	Records retained after title/abstract screening and assessed in full text.	269
Full-text reports excluded, with reasons	Excluded per reasons (a)–(d) listed in Section 2.2.	135
Studies included in core corpus	Final curated corpus reported in Table 4 and Figure 1.	134

illustrates the PRISMA-style literature screening flow and

Table 25. Synthesis of review findings organized by the seven guiding review questions (RQ1–RQ7, Section 1.2).

RQ	Primarily Addressed in	Synthesized Finding	Main Identified Gap
RQ1	Section 5, Section 6 and Section 13	Serverless has evolved from cloud-only FaaS to continuum-native, policy-aware execution; runtime substrates (containers, microVMs, WebAssembly) and platform ecosystems (Knative, OpenWhisk, OpenFaaS, major commercial FaaS) are increasingly mature (Table 5).	Limited systematic cross-platform and edge-scale comparison (Table 5; Section 13).
RQ2	Section 7 and Section 8	Reactive/predictive autoscaling and warm pool management reduce cold start latency substantially, with published mechanism-level results reporting reductions of up to 78.95% in code-loading latency and up to 42.05% in end-to-end response latency (Section 14); placement and offloading increasingly use topology-aware and DRL-based policies (Table 5).	Energy, carbon, and security costs of warming and migration remain underreported relative to latency gains (Table 21, Lesson 2; Section 13).
RQ3	Section 9	DAG-based workflows, function fusion, and data-locality patterns support composition, but stateful edge FaaS support is comparatively immature (Table 5).	State migration, trust, and carbon constraints are weakly integrated into workflow and state management mechanisms (Table 5; Table 21, Lesson 4).
RQ4	Section 10	Evidence for AI-, DRL-, and federated learning-assisted orchestration is growing rapidly, including serverless federated learning and digital twin deployment (Table 5; Section 4).	Explainability, robustness, and real testbed validation of learned controllers remain limited (Table 5; Table 21, Lesson 5).
RQ5	Section 11	Security, trust, and governance evidence is an emerging, cross-cutting category covering Denial-of-Wallet detection, provenance, attestation, and secure offloading (Table 3, Table 6).	Security is rarely treated as a first-class scheduling constraint alongside latency and cost (Table 5; Table 21, Lesson 3).
RQ6	Section 12; quantified in Section 13	Sustainability studies form a distinct, cross-cutting evidence category; independently measured figures cited in Section 13 show spatial carbon-aware scheduling achieving 20–85% footprint reductions against a bounded 0.85–12.67% migration overhead.	Carbon-aware warming and scheduling remain markedly less mature than autoscaling and cold start mitigation (Section 2.4 imbalance discussion; Table 21, Lesson 2).
RQ7	Section 13, Section 14 and Section 17	Industrial platforms are usability-mature but limited in research transparency (Table 21, Lesson 6); open benchmark artifacts (Azure Functions trace, SeBS, FunctionBench, EdgeFaaSBench) partially cover the evaluation dimensions in Table 19 (Section 14).	A standardized, reproducible evaluation specification and a unified benchmark library remain missing; Table 22 identifies cross-domain fusion (space–air–ground, digital twin, vehicular serverless) as a further open direction.

shows synthesis of review findings.

20. Conclusions

Cloud–edge environments are a new paradigm for distributed computing, and serverless functions play a major role in this new paradigm. While this model shares the advantages of event-driven, elastic, and developer-abstracted clouds, it also poses challenging lifecycle decisions on runtime selection, autoscaling, cold start mitigation, placement, offloading, migration, workflow composition, state management, security, trust, cost, energy, and carbon.

This review has demonstrated that mechanisms need to be examined together in the field. Cold starts and energy use are affected by autoscaling; latency, trust and data locality are affected by placement; state and fault isolation are affected by workflow composition; explainability and reproducibility are affected by AI-assisted control; and sustainability relies not on a single function invocation, but on the entirety of the execution path. Cloud–edge serverless computing is thus a multi-objective orchestration and governance problem and the proposed taxonomy and integrated framework places it in that context.

The future of serverless platforms need to be adaptive, trustworthy, interoperable and sustainability conscious. They will need to deliver elastic function execution with the exposure of evidence regarding function run sites, rationale for placement decisions, how state was managed, security policies, cost and carbon impact. Progress in the future will rely on the ability to have reproducible benchmarks, carbon-aware control of lifecycle, stateful abstraction of edge functions, trust-aware placement, cross-provider portability and explainable AI-driven orchestration. This paper brings all these challenges together into the same critical review to serve as a starting point for researchers and practitioners who are designing serverless systems on the cloud–edge continuum.

The actionable takeaways of this review are made explicit here and differentiated by audience, rather than restating the taxonomy above. For platform designers and engineers, three concrete engineering priorities emerge from the evidence synthesized in Section 6, Section 7, Section 8, Section 9, Section 10, Section 11, Section 12, Section 13 and Section 14: (1) expose placement and warm pool decisions as inspectable evidence (run-site, rationale, energy/carbon cost) rather than opaque scheduler internals, since Section 13 shows that today’s commercial and open-source platforms alike withhold exactly this telemetry; (2) budget explicitly for cross-region migration overhead when implementing spatial carbon-aware scheduling, since the measured overhead is bounded (≈8–13% of the optimized footprint metric in the worst case reported in Section 13) but not zero, so migration-aware admission control is preferable to unconditional shifting; and (3) adopt or contribute to the open benchmark artifacts identified in Section 14 (the Azure Functions trace, SeBS, FunctionBench, EdgeFaaSBench) as a default evaluation baseline rather than building bespoke, non-reusable test harnesses for every new placement or autoscaling proposal. For researchers, the synthesis points to two specific, underexplored problems rather than a generic call for “more work”: first, no reviewed study jointly reports cold-start probability, placement locality, and carbon intensity for the same workload under the same scheduler, which is the precise multi-objective evaluation gap identified in Section 12 and Section 17 and the reason Table 22 specifies joint evaluation metrics rather than single-objective ones; second, the state management literature (Section 9) and the digital twin and vehicular serverless literature (Section 17) each treat long-lived state differently (workflow context, twin synchronization state, and vehicle trajectory state, respectively), and reconciling these into one portable state locality abstraction is, on the evidence reviewed here, still an open architectural problem rather than an implementation detail. These takeaways are intended to be falsifiable and specific enough to guide a follow-up empirical study or a platform roadmap, rather than a restatement of the taxonomy presented earlier in this review.