Rise of the Planet of Serverless Computing: A Systematic Review

1 INTRODUCTION

• Serverless computing’s distinctive characteristics pose challenges to developing and deploying serverless applications.The review frames these challenges against a paradigm that lets developers focus on application logic at function granularity without managing underlying infrastructure.Source: §1 · p. 1
• The authors identify a lack of thorough analysis of the field’s research scope and depth, making it difficult to grasp studied directions and existing solutions.They say this gap may impede best software practices and the long-term evolution of the ecosystem.Source: §1 · p. 2
• The review analyzes 164 papers to construct a taxonomy of 17 research categories, including performance optimization, programming frameworks, migration, cost, and testing.It also classifies studies and elaborates on proposed solutions within each research direction.Source: §1 · p. 2
• The review examines experimental platforms, validation, datasets or code availability, and publication venues across the selected research.These analyses accompany its account of research directions and proposed solutions.Source: §1 · p. 2
• The authors discuss open challenges and promising opportunities, and share study data to support replication and updates to the results.The paper also outlines the organization of its background, methodology, research analyses, and opportunities sections.Source: §1 · p. 2

2 RELATED WORK

• Platform-focused reviews cover architecture, development options and constraints, and technology features across prominent serverless platforms.Li et al. discuss architecture implications; Grogan et al. compare development options and constraints; Yussupov et al. review technology aspects.Source: §2 · p. 3
• Focused surveys address topics such as cold starts and resource management, while Mampage et al. review resource-management work using a proposed taxonomy.These narrower studies do not provide a global overview of the research state.Source: §2 · p. 3
• Hassan et al. report publication statistics and use cases but do not summarize or classify specific solutions.The authors identify a gap in comprehensive coverage of both research scope and in-depth analysis of solutions.Source: §2 · p. 3

3.1 Evolution of Serverless Computing

• Compared with PaaS, serverless removes most underlying-server management and adds demand-based automatic scaling, though it cannot support long-running processes or stateful applications.PaaS developers still handle some management and configuration, whereas serverless providers manage infrastructure provisioning.Source: §3.1 · p. 4
• Serverless functions are smaller execution units than microservices, and providers manage their infrastructure instead of developers handling scalability, fault tolerance, and load balancing.Both approaches decompose applications into independently developed, deployed, and managed components.Source: §3.1 · p. 4

3.2 Architecture of Serverless Computing

• The architecture combines optional BaaS with stateless, event-driven FaaS functions, which platforms trigger from bound events, provision runtime instances for, then recycle after execution.Triggers include HTTP requests, cloud-storage updates, and notifications; instance setup can involve initialization, application transmission, and code loading.Source: §3.2 · pp. 4–5

3.3 Key Characteristics of Serverless Computing

• Developers upload function code without configuring environments, while platforms auto-scale and retain instances briefly before scaling to zero; zero scaling can cause cold starts.Platforms may scale horizontally or vertically according to workload dynamics.Source: §3.3 · p. 5
• Billing tracks allocated or consumed resources per fine-grained execution unit, while compute and storage scale independently; platform-specific execution, package, disk, and memory limits preserve autoscaling.Event-driven functions incur no cost when they are not triggered.Source: §3.3 · pp. 5–6

3.4 Serverless Platforms

• Commercial AWS Lambda, Azure Functions, and Google Cloud Functions hide platform details and create vendor lock-in, motivating open-source alternatives including OpenWhisk, OpenFaaS, and OpenLambda.The passage also notes Kubernetes as a factor in open-source platforms' recognition and popularity.Source: §3.4 · p. 6
• CLI and API access are common across platforms; all but Google Cloud Functions support custom-container deployment, trading language and package flexibility for container-management work.Commercial platforms provide tailored monitoring and logging, while open-source platforms generally use external tools; commercial platforms also provide native access management, unlike open-source platforms, which rely on their hosting environments.Source: §3.4 · p. 8

3.5 Comparison with Traditional Software Development

• Non-cloud developers coordinate and maintain components and implement server-side functionality, facing high physical-server failure rates; cloud developers rent resources without buying servers, reducing some maintenance but retaining server-side coordination; serverless developers almost do not manage complex server tasks.Source: §3.5 · p. 9
• Serverless applications can comprise event-triggered functions and optional cloud services; functions are short-lived and stateless.Traditional non-cloud development involves technology and framework selection, environment setup, resource preparation, and backend implementation, while cloud development retains infrastructure configuration and security work.Source: §3.5 · p. 9
• Traditional invocations depend on client-side calls and involve complex server processes, while serverless invocations rely on developer-predefined events.Source: §3.5 · p. 10
• Serverless applications have inherent function-timeout, memory, and local-disk limits, whereas cloud applications generally face no execution limits if enough resources are rented.Source: §3.5 · p. 10
• Traditional applications run in developers’ limited local environments, while cloud and serverless applications can execute in cloud environments with provisioned resources [27, 195, 243].Source: §3.5 · p. 10
• Inactive serverless environments can cause cold starts and long preparation times, while provider-managed runtimes activate on triggers to handle bursty workloads.The paper notes efforts to alleviate cold starts.Source: §3.5 · p. 10
• Serverless developers pay only for resources allocated or consumed and avoid complex underlying-task management, unlike traditional hardware, maintenance, and always-on costs.Source: §3.5 · p. 10
• Serverless platforms lack rich testing and debugging support because event-driven, distributed, platform-masked architectures complicate application structure and make execution flows harder to reproduce.Source: §3.5 · p. 10

4 METHODOLOGY

• The review follows Kitchenham’s standard guidelines for evaluating and interpreting research relevant to a topic area.The authors describe this as their systematic literature-review protocol.Source: §4 · p. 11

4.1 Research Questions

• Four questions address research directions, existing solutions, experimental settings and evaluation, and publication venues.Evaluation includes implementation platforms, experimental validation, and whether datasets or code are shared and accessible.Source: §4.1 · p. 11

4.2.1 Literature sources.

• The authors searched seven online engines and databases, including ACM Digital Library, IEEE Xplore, Google Scholar, ScienceDirect, Scopus, SpringerLink, and DBLP.The sources are identified as literature sources for the collection process.Source: §4.2.1 · p. 12

4.2.2 Search string.

• The search combined serverless-related terms with computing and application-related terms, was run on January 1, 2022, and returned 398 papers published from November 2014 onward.The search covered papers through January 1, 2022.Source: §4.2.2 · p. 12

4.2.3 Inclusion and exclusion criteria.

• Included papers had to address serverless computing with a design, algorithm, optimization, or general idea and be written in English; the authors excluded surveys and unavailable full texts.The review also excluded benchmark suites, dissertations, and preprints submitted to the arXiv website.Source: §4.2.3 · p. 12

4.2.4 Snowballing.

• After screening and duplicate removal, 118 initial papers were expanded by forward and backward snowballing, yielding 164 papers in total.Snowballing was repeated until no new relevant papers were identified; it added 46 papers.Source: §4.2.3 · p. 12, §4.2.4 · p. 12

4.3 Taxonomy construction

• The authors used a random 70% sample of research papers for bottom-up open coding to build an initial taxonomy, then had two authors independently label the remaining 30%, achieving Cohen’s κ = 0.849.Source: §4.3 · pp. 12–13

Research directions

• The taxonomy contains 17 non-divisible research directions; Performance is the largest, accounting for 40.85%, followed by Programming Framework at 19.51% as the second-largest direction.Source: §5 · pp. 13–14

Performance

• Within performance optimization, cold-start work accounts for 56.67% (34/60), while runtime-performance work accounts for 43.34% (26/60).Cold starts add request latency during runtime-environment preparation; runtime performance covers function execution and communication overhead.Source: §5 · p. 14
• Runtime-performance studies address function execution and communication; communication accounts for 69.23% (18/26), compared with execution’s 30.77% (8/26).The review links communication overhead to stateless functions, external data fetching, and the lack of mature point-to-point networking between functions.Source: §5 · p. 14

Programming Framework and Resource Management

• Programming-framework studies divide into specific frameworks at 59.38% (19/32) and general frameworks at 40.63% (13/32), addressing varied application requirements.The review describes resource management as the third-largest direction, covering resource requirements and platform efficiency.Source: §5 · p. 14

Other research directions

• The eight other directions include Stateful FaaS (4.88%), Application Modelling (4.27%), Application Migration (6.10%), Cost (8.54%), Multi-Cloud Development (1.83%), Accelerator Support (2.44%), Security (3.05%), and Testing and Debugging (1.22%).These proportions are reported out of 164 papers.Source: §5 · pp. 14–15
• Stateful FaaS targets broader workloads than stateless functions, while application-modelling studies seek clearer representations of serverless applications and their dependencies.Application-migration work concerns moving legacy applications to serverless platforms.Source: §5 · p. 15
• Multi-cloud work explores using multiple providers; accelerator studies address CPU-dominated runtimes that cannot use GPUs or FPGAs, while platform and application opacity contributes to security concerns.The review also identifies trust concerns between developers and cloud providers.Source: §5 · p. 15
• Testing and debugging are challenging because the platform hides underlying implementation and serverless functions are independent and event-driven, making application correctness difficult to determine.Source: §5 · p. 15

6.1 Resource Management

• Prior work found inconsistent and incorrect concurrency limits, difficulty supporting bursty workloads, and inefficient resource allocation; Sequoia was introduced as an effective QoS scheduler to alleviate these problems.A controller adjusts working threads for each QoS class and uses a QoS violation index to determine required resources rather than the previous work’s prediction module.Source: §6.1 · p. 16
• The review notes that platform-wide QoS solutions may use coarse factor granularity that does not adapt to developers’ task types, while resource-management work faces an information gap [70].Infrastructure changes may be hidden from developers and can affect application features.Source: §6.1 · pp. 16–17
• Prior work dynamically adjusts CPU usage limits according to serverless applications’ performance-requirement similarity and adjusts container CPU-share resources; these studies mainly focus on CPU resource adjustment.Source: §6.1 · p. 16
• Application-aware management uses execution history and network latency to predict memory needs or placement, while Kraken uses workflow structure and invocation probability to provision containers.These strategies aim to avoid over-provisioning while preserving application performance.Source: §6.1 · p. 17
• For bursty, stateless, short-lived applications, a core-granular centralized scheduler assigns functions to cores and maintains a global cluster view.Another architecture uses Harvest VMs, described as a faster, cheaper alternative to VMs, with measurement results informing its design.Source: §6.1 · p. 17

6.2.1 Performance Prediction.

• Per-function regression models account for CPU heterogeneity and memory settings but require separate training, while Sizeless uses synthetic-function resource data to predict latency across memory sizes.The regression models predict runtime measures such as CPU user- and kernel-mode time.Source: §6.2.1 · pp. 18–19
• Statistical models use cold-start rates and latency, warm-instance arrival rates, and expiration rates to predict platform performance and reduce resource waste while guaranteeing QoS.The models use a system with a Markovian arrival process.Source: §6.2.1 · p. 19
• COSE learns function performance from execution logs using Bayesian Optimization, while Lin and Khazaei model application response time in a probabilistic graph; history-based approaches lack data for new functions.COSE predicts a configuration that meets user-specified performance, and the graph incorporates application structure and function response times.Source: §6.2.1 · p. 19

6.2.2.1 Cold Start Performance.

• Studies address serverless cold starts through chain structure, while prewarm preparation learns characteristics such as structure and invocation; irregularly called functions make setting a pool’s service-window size challenging.Source: §6.2.2.1 · p. 20
• Data caching can preload binaries and libraries or share runtimes to reduce cold-start and container-preparation latency, as in SOCK and SAND.SOCK and Pipsqueak cache interpreters and commonly used libraries; SAND uses application-level sandbox runtime sharing.Source: §6.2.2.1 · pp. 20–21
• Caching all required libraries can increase resource overhead, and cache policies may not fit real workloads; Mohan et al. cache network resources in pre-created containers to reduce startup overhead.Their approach targets network namespace creation and initialization during concurrent container startup.Source: §6.2.2.1 · p. 21
• Data caching can alleviate cold starts, but may cause high resource overhead, imbalanced consumption, performance interference, and uncertainty about real-world cache policies.Fuerst et al. treated keeping instances warm as caching and designed FaasCache with caching-based keep-alive policies.Source: §6.2.2.1 · p. 21
• Existing schedulers may ignore container lifecycle, so CAS uses an affinitive worker to track container states and distribute requests.CAS targets scheduler inefficiency in handling container creation, use, pause, and eviction.Source: §6.2.2.1 · pp. 21–22
• For multi-tenant, high-concurrency workloads, FPCSch schedules available containers to requests to reduce cold starts and obtain stable performance.The review notes that existing schedulers showed erratic behavior under these workload conditions.Source: §6.2.2.1 · p. 22
• Function fusion can place independent functions on one instance, while invocation-history mining identifies dependencies for co-locating connected functions and reducing cold starts.The approaches leverage application structure and function dependencies.Source: §6.2.2.1 · p. 22
• Snapshot methods restore saved function state to speed startup without requiring main memory during inactivity, but differing input payloads can delay execution until all data loads.Snapshot-based approaches avoid creating runtime environments from scratch, but their startup advantage may not hold when invocation payloads differ substantially.Source: §6.2.2.1 · pp. 22–23
• 95% longer execution time on average was observed for Catalyzer snapshot runs than for resident-in-memory execution; REAP preloads stable guest-memory pages.Frequent page faults from pages being written to the snapshot state caused high latency.Source: §6.2.2.1 · p. 23
• Architecture work explored language-based isolation, WebAssembly, and Unikernels as lightweight runtime designs; the review identifies balancing security, performance, and flexibility as a future trend.The review suggests generalizing lightweight designs to commodity and open-source serverless platforms.Source: §6.2.2.1 · pp. 23–24

6.2.2.2 Runtime Performance.

• Runtime-performance optimization addresses function execution and function communication.Source: §6.2.2.2 · p. 24

Memory configuration

• Lin and Khazaei use a performance model and heuristic to choose memory configurations that minimize average application response time under budget constraints.Allocated memory can affect response time, although response time becomes insensitive to memory once allocation is large enough.Source: §1 · p. 25

Function scheduling

• Platforms may ignore application type and invocation frequency, allowing functions to share a VM and affect execution; scheduling can reduce CPU and network competition among instances.Source: §1 · p. 25
• For bursty or real-time workloads, predictive container management and admission control are proposed to support guaranteed invocation rates with minimal performance effect.Source: §1 · p. 25
• FaaSNet organizes VMs into function-based trees and dynamically balances their topology to adjust VM joining and serve bursty requests.The work addresses custom-container deployments that pull images larger than 1.3 GB, which can create severe network-bandwidth problems under bursts.Source: §1 · p. 25

Architecture design

• Atoll decouples sandbox allocation from scheduling and uses deadline-aware scheduling and co-designed load balancing to handle unpredictable arrivals under user-specified deadlines.It is designed for short-lived serverless functions and to maximize request processing within those deadlines.Source: §1 · p. 25
• Chadha et al. use an LLVM-based Just-in-Time compiler for Python to optimize compute-intensive serverless functions.Source: §1 · p. 25
• Carreira et al. report runtime optimization benefits, with repeatedly executed hot-start code running optimized, and present Ignite to share optimization information across runtimes to reduce profiling and compilation overhead.Source: §1 · p. 25
• Architecture redesigns require substantial effort but may significantly improve function-runtime performance.The review contrasts this effort with the relative ease of adjusting allocated memory.Source: §1 · p. 25

2. Function Communication

• Faasm and Nightcore provide equivalent internal function-call functionality, but Faasm shares memory within a WebAssembly-isolated process while Nightcore co-locates requests in a container.Both require application modification; Nightcore also supports arbitrary invocation patterns and optimizes inter-request I/O through efficient threading.Source: §2 · p. 26
• Faastlane minimizes interaction latency for unmodified applications by using simple load/store data sharing and placing workflow functions in a shared virtual address space.Faasm and Nightcore, by contrast, require modifying the serverless application.Source: §2 · p. 26
• Cache-based approaches reuse data across invocations or place caches near computation, while HydroCache’s repeated worker setup can contribute to function-execution tail latency.Lambdata declares function read/write intents and co-locates related functions; HydroCache uses Anna for low-latency access and transactional causal consistency.Source: §2 · pp. 26–27
• Cloudburst and HydroCache rely on Anna-specific consistency semantics and protocols, Cloudburst omits caching configuration details, and prior cache approaches had not considered scaling.OFC used machine learning to predict caching efficiency and memory usage, while FaaT bundled an in-memory cache with replacement and persistence policies for autoscaling and transparency.Source: §2 · p. 27
• Storage systems target data redundancy, scalable performance and cost, and locality through deduplication, multi-tier placement, or computation near object storage.Sanity deduplicates near event sources; Pocket and Locus balance performance and cost across storage tiers; Zion moves computation into the data pipeline.Source: §2 · p. 27
• SONIC exposes a unified API to select among hybrid data-passing methods using application-specific factors after existing methods performed poorly across serverless scenarios.It can also use optimized storage such as Pocket and Locus.Source: §2 · p. 27
• Boxer enables direct function-to-function communication on existing serverless platforms using TCP hole punching to bypass conventional network constraints.The cited work did not yet support large-scale communication-intensive applications or high-throughput, low-latency networking, leaving scalability a future challenge.Source: §2 · pp. 27–28

6.3 Stateful FaaS

• A stateful application model represents functions and required data as a stateful dataflow graph, automatically sharing data to support scalability and low latency.Another approach uses a stateful function language and compiler to generate cloud infrastructure that supports application state access.Source: §6.3 · p. 29
• Beldi records application state and logs, then re-executes unfinished functions for at-least-once semantics, which can expose fractional writes after failures.Its log-based refinements target stateful functions on existing serverless platforms.Source: §6.3 · p. 29
• Boki exports a shared-log API and separately optimizes reads and writes, but developers must adapt their applications to its different development model.Its shared-log approach was motivated by Beldi’s design.Source: §6.3 · p. 29
• Cloudburst uses Anna storage with flexible auto-scaling, while Crucial maps function invocations to threads and uses distributed shared objects for strong consistency.Crucial’s approach also simplifies global state semantics across threads.Source: §6.3 · p. 29
• AFT coordinates database accesses through a fault-tolerant shim and uses atomicity and idempotence for exact-once semantics, but requires server modifications that limit platform portability.The approach addresses the fractional writes that can arise with Beldi’s at-least-once execution.Source: §6.3 · p. 29
• Stateful FaaS aims to spare developers from concurrency control and fault tolerance, while raising state-isolation and consistency concerns across centralized or separate databases.A centralized database must prevent one application’s malicious requests from observing another’s state; separate databases require addressing isolation and consistency.Source: §6.3 · p. 29

6.4 Application Modelling

• F(X)-MAN modeled services and connectors as entities; TOSCA lacked platform-requirement representation and support for lifecycle aspects including deployment, requirements, and metrics; no specification language modeled serverless applications platform/cloud-independently.Source: §6.4 · p. 30
• Configuration-based analysis addresses event-driven modeling complexity: Obetz et al. derive a call graph of functions, events, and services, while Samea et al. transform source models into implementations.Configuration changes can reflect low-level implementation, and configuration information may be supplied in files such as .yml.Source: §6.4 · pp. 30–31

6.5 Programming Framework

• 40.63% of frameworks target general applications, while 21.88% target IoT, the most widely investigated specific-application scenario.These are the two largest categories reported in the framework distribution.Source: §6.5 · p. 31, Figure 5 · p. 32

6.5.1 Specific Framework.

• NumPyWren extracts parallel task graphs from data dependencies and uses distributed-object-store intermediate state to reduce processing latency in serverless linear algebra.It builds on PyWren, a queue-based master-worker approach that runs functions in parallel when possible.Source: §6.5.1 · p. 32
• ExCamera uses a state machine for fine-grained control of video-chunk tasks, while Sprocket supports sophisticated processing with dynamic task creation and parallelism.These frameworks address the mismatch between video workloads that invoke thousands of execution threads quickly and fine-grained parallelism that does not support video encoders.Source: §6.5.1 · p. 32
• For data-intensive IoT, Cheng et al. enable movement between code and data; tinyFaaS targets constrained edge nodes with alternative messaging protocols for low-power devices.The review identifies event-driven programming and separated computation and storage as sources of inefficiency for data-intensive or dataflow IoT applications.Source: §6.5.1 · p. 32
• IoT deployment approaches include AuctionWhisk for function placement across geo-distributed sites, STOIC for edge/public-cloud cooperation, Dyninka for multi-tier composition, CSPOT for device-to-cloud hosting, and FDN for heterogeneous-cluster delivery.CSPOT also incorporates robustness, compatibility, security, and record-and-replay debugging; FDN routes functions according to computation and data needs.Source: §6.5.1 · pp. 32–33
• Pérez et al. introduced a highly parallel event-driven programming model combining middleware that simplifies development and deployment with customized container-image runtimes that bypass the language limitation; a MapReduce framework partitioned input by allocated memory.For MapReduce jobs, Enes et al. relied on operating-system-level virtualization to design a scalable framework to provide resources.Source: §6.5.1 · p. 33
• SIREN used deep reinforcement learning to schedule function instances and memory sizes dynamically across ML training epochs, reducing training cost.Source: §6.5.1 · p. 33
• Because some trained models exceed serverless deployment-size limits, Gillis and AMPS-Inf use automatic model partitioning.Source: §6.5.1 · p. 33
• Ali et al. found ML inference could not benefit from serverless computing without batching; BATCH uses a dispatching buffer and adaptive batching parameters.Source: §6.5.1 · p. 33
• IoT-based serverless frameworks are the most widely investigated specific scenario, pointing to a potential future trend in edge serverless computing.Source: §6.5.1 · p. 33

6.5.2 General Framework.

• GlobalFlow addresses cross-region function orchestration with copy-based and connector-based strategies; connectors group regional functions into sub-workflows to support data locality.Source: §6.5.2 · p. 34
• WUKONG uses decentralized static and dynamic scheduling, task clustering, and delayed I/O to improve locality and resource use, but its weak isolation may add security risks.Source: §6.5.2 · p. 35
• Kappa uses checkpoints and concurrency mechanisms for parallel applications, while gg introduces an intermediate representation for managing computation and storage.Source: §6.5.2 · p. 35
• General frameworks address orchestration, scheduling, runtime, abstraction, and architecture; they broaden supported application types but require deterministic execution paths.Dynamic workloads may have mutable paths, making these frameworks unsuitable.Source: §6.5.2 · p. 35

6.6 Application Migration

• Manual migration studies provide step-by-step guidance but mainly address specific application classes, including web applications and AI or deep-neural-network inference.One web approach keeps scalable, resource-intensive components as microservices while transforming short-lived components into serverless functions.Source: §6.6 · p. 36
• Automated tools target Java or Node.js monoliths by parsing code and transferring it into event-driven functions.The review identifies automated conversion as an area where a mature approach is still lacking.Source: §6.6 · p. 37
• A generic migration approach remains challenging across application types, with vendor lock-in, function granularity, and state management among the factors to consider..Source: §6.6 · p. 37

6.7.1 Cost Prediction.

• Cost prediction studies include regression-based estimates that combine platform pricing policies with runtime predictions and statistical-learning approaches.The cited regression approach models runtime across CPU and memory settings; COSE learns cost relationships for unseen configurations from trace logs.Source: §6.7.1 · pp. 37–38

6.7.2 Cost Optimization.

• Cost optimization studies address function scheduling, hybrid serverless-and-VM deployment, and resource adjustment under performance constraints.Other described options include function fusion and placement framed as a constrained shortest-path problem.Source: §6.7.2 · p. 38
• The billing pattern discussed is effective for CPU-bound workloads, while I/O-bound workloads may pay for underutilized computation resources.The review suggests that broader billing factors such as networking and storage may support fairer cost prediction.Source: §6.7.2 · p. 39

6.8 Multi-Cloud Development

• Multi-cloud proposals include a peer-to-peer architecture using container-cluster management and a framework for transparently running regular Python code across serverless platforms.Vasconcelos describes a FaaS Cluster, FaaS Proxy, and Multi-Cloud Resource Allocator.Source: §6.8 · p. 39
• Cloud services still cannot communicate and interact across providers, which may make multi-cloud collaboration inefficient.The reviewed work proposes architectures intended to let developers benefit from multiple clouds.Source: §6.8 · p. 39

6.9.1 GPU Support.

• Kim et al. integrated NVIDIA-Docker into an open-source framework to deploy GPU-supported containers, but each GPU cannot serve multiple function invocations simultaneously.The per-GPU concurrency constraint is identified as the approach’s biggest disadvantage.Source: §6.9.1 · p. 40
• Naranjo et al. tried remote rCUDA access and PCI passthrough; the review reports GPU virtualization as an efficient, accelerated approach that lets functions share GPUs.Source: §6.9.1 · p. 40

6.9.2 FPGA Support.

• Ringlein et al. designed a serverless architecture with disaggregated FPGAs, while BlastFunction supports FPGA time-sharing and multi-tenancy.The review notes that accelerator support may not be economically viable for most application types, while heterogeneous accelerator mixes may open a research direction.Source: §6.9.2 · p. 40

6.10 Security

• Se-Lambda combines SGX and a WebAssembly sandbox to protect the API gateway, with SGX providing a trusted environment for sensitive data.Source: §6.10 · p. 41
• Security work addresses misconfiguration and overprivileged functions, which the review identifies as threats and grounds for adding security studies to configuration analysis.Source: §6.10 · p. 41

6.11 Testing and Debugging

• Testing studies are relatively few; the review highlights function/service interactions and distributed tracing as useful concerns for testing and locating errors in event-driven execution.Watchtower uses record-and-replay so developers can recreate and re-execute an application from a specific state locally.Source: §6.11 · p. 42

• 31.49% of evaluated platforms are custom systems, while AWS Lambda accounts for 30.94% and is the second most widely used platform.Source: Figure 6 · p. 43, §7 · p. 43
• OpenWhisk accounts for 13.26% of platforms, while less-used platforms collectively account for 4.42%.The “Others” category includes Alibaba Cloud Function Compute, Knative, Fission, Kubeless, and Huawei’s FaaS Framework.Source: Figure 6 · p. 43, §7 · p. 43
• 45.12% of studies share datasets or code, while 54.88% do not; the review says more studies describe solution design and implementation than provide reproducibility possibilities.Source: §7 · p. 44
• 95.95% of shared dataset or code links are accessible, while 4.05% are inaccessible.Source: §7 · p. 44
• 93.90% of existing solutions are evaluated using experimental validation, while 6.10% are not experimentally validated.Source: §7 · p. 43, Figure 7 · p. 44

• SoCC, TPDS, and CLOUD are identified as the top venues, accounting for 28 of the 164 papers.Source: §8 · p. 44
• Venue coverage spans multiple research directions: OSDI, SOSP, EuroSys, and USENIX ATC cover six, while SoCC, TPDS, and CLOUD cover twelve.Source: Table 23 · p. 45, §8 · p. 45
• Publication venues mainly represent software engineering and systems communities, addressing problems on the application side and the serverless-platform side.Software engineering-related journals and systems-related venues are both represented.Source: §8 · p. 45
• The review links unresolved issues on both sides to developers not yet enjoying serverless computing’s advantages of easy development and fast application execution.Source: §8 · pp. 45–46

Generalizability of application conversion approaches

• Generic application conversion remains unavailable; future approaches must address application type, vendor lock-in, function granularity, event-driven transformation, cloud-service selection, and state communication.Existing conversion approaches target only a few application types.Source: §9 · p. 46

Cold start performance problem of serverless applications

• Cold-start research should move beyond accelerating container creation or runtime initiation to optimize application initialization, while addressing sandbox isolation and flexibility.Application initialization may become a large share of cold-start time once runtime initialization is faster.Source: §9 · p. 46

Performance variability of serverless functions; Monitoring tools

• Performance prediction must account for dynamic performance and platform opacity; monitoring also remains insufficient, although third-party tools may trace serverless applications.Auto-scaling makes function performance variable and resource allocation dynamic, while platforms expose little information about underlying environments.Source: §9 · pp. 46, 48

Data privacy of IoT applications

• IoT data privacy remains unaddressed; a proposed opportunity is an encrypted index that supports operations or query evaluation without requiring decryption.Distributed edge devices may collect private data and lack unified cloud management, leaving them vulnerable to attacks.Source: §9 · p. 47

Testing tools

• Serverless applications lack mature testing tools, in part because local tests must mock unknown deployed containers; serverless-specific testing tools are a research opportunity.Applications may also require integration testing across dependent functions.Source: §9 · p. 47

Security and efficient direct communication between serverless functions

• Temporary storage-based function communication raises security and overhead concerns; research should develop secure platforms and efficient direct networks for communication-intensive applications.Boxer supports direct communication, but may not provide high-throughput, low-latency networking at large scale.Source: §9 · p. 47

Effectiveness of the pricing model

• Current computation-based billing may be costly and inefficient for I/O- or disk-intensive workloads, motivating resource-specific billing and dynamic pricing prediction and optimization.The proposed billing patterns should consider CPU, memory, networking, and storage.Source: §9 · pp. 47–48

Fine-grained resource configuration on application development; Heterogeneous accelerator support

• Research opportunities include optional fine-grained controls such as network conditions and function placement, and heterogeneous CPU, GPU, FPGA, and TPU support despite implementation and economic challenges.Additional accelerator challenges include new schedulers, resource allocation patterns, billing models, and hardware restrictions.Source: §9 · p. 48

Observability

• Serverless observability remains an opportunity because current metrics omit resource consumption and infrastructure performance needed to understand applications and platforms.The paper notes CPU utilization and network condition as examples of missing metrics.Source: §9 · p. 48

Representativeness and completeness of benchmark dataset

• A representative, complete benchmark dataset is needed because serverless studies lack a uniform dataset, and diverse applications can expose weaknesses in generic techniques.The paper identifies dataset construction as a promising research opportunity.Source: §9 · p. 48

Computing continuum

• Combining serverless with mobile, edge, and cloud technologies can form a computing continuum that converges heterogeneous infrastructures and enables disruptive applications.Source: §9 · p. 48

Configuration management

• Configuration questions are the second-largest category of developer challenges, making automated error detection and serverless-specific configuration mechanisms promising research directions.Fixing configuration errors can reduce deployment time and misconfiguration risk while easing developers’ management burden.Source: §9 · p. 49

10 OPPORTUNITIES FOR PRACTITIONERS

• Practitioners can build a serverless-related custom system or use AWS Lambda or OpenWhisk.The review identifies these platforms in its discussion of experimental platforms.Source: §10 · p. 49
• Nearly half of the studies have open-source datasets or code that practitioners can access to facilitate development.Source: §10 · p. 49
• 36.84% (7/19) of specific frameworks target IoT applications.The review notes that practitioners also develop many IoT applications.Source: §10 · p. 49
• Performance is a main focus in the literature, with optimization research covering cold starts, function execution, and communication.For latency-sensitive applications, practitioners can identify the bottleneck and consult the corresponding solution.Source: §10 · p. 49
• For cold starts, practitioners can try fusing functions; for execution performance, they can infer an optimal memory size from historical execution information.The review cites function fusion and memory-size inference as examples.Source: §10 · p. 49
• Serverless providers lack standardization and interoperability, and the portability of code that depends on cloud-specific services remains an open question.The section points to open-source platforms and standards such as cloud events in discussing this challenge.Source: §10 · p. 50
• A potential trend is combining low-code development with serverless to improve productivity and address business problems quickly.The section says low-code can reduce project burden and accelerate application transformation.Source: §10 · p. 50

11 CONCLUSION

• The review collected and analyzed 164 papers to construct a taxonomy of 17 serverless-computing research directions.Source: §11 · p. 50
• It classifies studies and elaborates on solutions, examines experimental settings and evaluation, and maps publication venues.Source: §11 · p. 50
• The review discusses open challenges and promising research opportunities for future serverless-computing research.Source: §11 · p. 50
• The analysis can reduce ambiguity and the entry barrier for novice researchers and practitioners.Source: §11 · p. 50
• The summarized taxonomy, solutions, distributions, and analyses are intended to help future researchers pursue topics and practitioners follow software-engineering practices.Source: §11 · p. 50