Epico: Long-Lived WebAssembly Components for High-Performance Serverless Stream Processing

Epico: Long-Lived WebAssembly Components for High-Performance Serverless Stream Processing Matteo Della Bartola1[0009−0009−8415−2522] , Valerio Besozzi1[0009−0002−8493−2122] , Patrizio Dazzi1[0000−0001−8504−1503] , and Marco Danelutto1[0000−0002−7433−376X]

arXiv:2608.02361v1 [cs.DC] 3 Aug 2026

Dept. of Computer Science, University of Pisa, Pisa, Italy matteo.dellabartola@phd.unipi.it, valerio.besozzi@phd.unipi.it, patrizio.dazzi@unipi.it, marco.danelutto@unipi.it

Abstract. While serverless computing is popular, its dominant Functionas-a-Service (FaaS) model is ill-suited for stream processing because its stateless, centrally orchestrated functions cannot efficiently handle continuous, low-latency event flows. We introduce Epico, a serverless runtime explicitly designed to resolve these inefficiencies at the runtime level. Epico executes pipeline stages as persistent WebAssembly components, enabling independent, zero-to-infinity autoscaling based on queue-depth SLOs and routing events directly between stages using broker-free ZeroMQ channels. To optimize short execution paths, it utilizes a credit-based sliding window to amortize inter-process communication costs. Evaluations demonstrate that Ahead-of-Time (AOT) compilation reduces cold-start latencies from hundreds of milliseconds to sub-millisecond ranges, while the credit window improves single-worker throughput by up to 4.3×. Compared to Apache OpenWhisk, Epico bypasses the orchestrator bottlenecks and container overheads that typically hinder FaaS streaming workloads. Keywords: WebAssembly · Stream Processing · Serverless Computing.

1

Introduction

Serverless computing is a cloud execution model that allows developers to deploy fine-grained, automatically scale applications without managing operational logic. Function-as-a-Service (FaaS) is the most widely adopted serverless model, characterized by event-driven execution and stateless, ephemeral functions that scale elastically. However, this model introduces significant overheads, particularly cold starts, which inflates latency when functions must be initialized from scratch. These architectural limitations become especially problematic when running continuous stream-processing pipelines on general-purpose serverless platforms. Framework like Apache OpenWhisk does not provide true pipeline parallelism; instead, they operate stages as distinct invocations coordinated sequentially by a central controller. This introduces an orchestrator bottleneck, as intermediate data must be routed through the controller before triggering subsequent stages. To address these challenges, we present Epico, a serverless stream-processing runtime that executes pipelines defined as linear Directed Acyclic Graphs (DAGs).

2

M. Della Bartola et al.

By replacing traditional containers with WebAssembly (Wasm) and the Webassembly System Interface (WASI), Epico achieves lightweight sandboxing with microseconds-level instantiation times. Our framework introduces three architectural contributions: (1) per-stage autoscaling, where each pipeline stage scales automatically and independently from zero to a configured maximum based on its input queue depth; (2) credit-based flow control, which maximizes throughput using a TCP-inspired sliding window protocol to amortize round-trip costs between dispatchers and workers; and (3) optimized execution supporting Ahead-of-Time (AOT) compilation, which is critical for maintaining predictable, low-latency cold starts in production-grade environments.

2

Background

Serverless. Serverless computing is a cloud computing execution model that allows users to deploy and execute fine-grained billed and automatically scaled applications, without having to address the underlying operational logic [1]. Depending on the level of abstraction, three main serverless service models can be identified: Function-as-a-Service (FaaS), Backend-as-a-Service (BaaS), and Container-as-a-Service (CaaS). Serverless computing can be positioned within the cloud computing hierarchy alongside Platform-as-a-Service (PaaS). However, serverless is distinguished by its event-driven invocation model, automatic scaling mechanisms, and emphasis on stateless and ephemeral services. Function-as-a-Service (FaaS). FaaS represents the most widely adopted form of serverless computing. In this service model, developers decompose applications into fine-grained, event-driven functions that are automatically deployed, executed, and scaled by the cloud provider. FaaS is characterized by the separation of computation from storage and an event-driven execution model [6], as functions are typically designed to be stateless and ephemeral, enabling elastic scaling from zero to virtually unlimited instances on demand. While this model enables elasticity and fine-grained resource utilization, it also introduces overheads, most notably the cold start, which impacts latency when functions are invoked after periods of inactivity due to the time required to initialize and configure a new execution environment from scratch before executing the triggered function. WebAssembly. Recent research has explored the use of WebAssembly [19] as lightweight execution environment for serverless platforms. WebAssembly provides language-level sandboxing with fast startup times and wide compatibility across programming languages. Approaches aim to reduce startup overheads and improve resource efficiency compared to traditional containerization. In addition, on top of the core WebAssembly specification, the WebAssembly System Interface (WASI) [23] provides a system-level interface that exposes modules that enable WebAssembly applications to interact with the underlying operating system. The WASI extension allows WebAssembly to be used not only for webbased applications. It is important to note that the WebAssembly specification defines a binary instruction format and execution model for a stack-based virtual

Epico: Serverless Stream Processing via Wasm

3

machine, but does not provide a reference runtime implementation. Consequently, several runtimes implementing the WebAssembly specification have emerged. Among these, Wasmtime [3], developed by the Bytecode Alliance, represents one of the most widely adopted standalone runtimes. It provides secure, isolated execution and full support for WASI, enabling functions to interact safely with the host operating system. Furthermore, it is designed to achieve microsecondlevel instantiation times, making it particularly suitable for mitigating cold-start overheads in serverless environments.

3

Epico

Epico-CLI EPICO RUN (JIT / AOT) EPICO BUILD (JIT / AOT) EPICO VALIDATE EPICO BOOTSTRAP

Epico-SDK EXPORT STAGE! MACRO

BUILD RUNTIME.YAML

Epico Runtime STAGE 1 DISPATCHER

WORKER-1

STAGE 2 DISPATCHER

AUTOSCALER

WORKER-1 AUTOSCALER

SUPERVISOR

=GRANDMASTER STAGE N DISPATCHER

WORKER-1 AUTOSCALER

LOGGER

Fig. 1: Proposed architecture of Epico

Overall Architecture Epico1 is a serverless stream-processing runtime in which the developer defines a pipeline as a linear Directed Acyclic Graph (DAG) of stages. Each stage is defined using Webassembly that exports a single typed entry point, process-event(ev, bench) -> (ev’, bench’), and scales automatically and independently from zero to a per-stage maximum based on its input queue depth. The runtime consists of three primary actors (Fig. 1): a GrandMaster, which owns the shared Wasmtime engine, supervises all dispatcher sub-processes, and coordinates the full lifecycle of a pipeline run, from loading and validating WebAssembly components to writing the summary telemetry upon shutdown, a Dispatcher for inter-stage communication, and a Logger for logging purposes. For each pipeline stage, the GrandMaster spawns a dedicated autoscaler thread that ticks every 1 ms. The autoscaler polls its corresponding stage’s dispatcher for queue depth via a ZMQ REQ/REP control socket and drives a vote-with-cooldown controller. Each tick contributes one vote in the direction implied by the current queue depth: a scale-up vote when queue depth exceeds an upper threshold, a scale-down vote when it falls below a lower threshold. The autoscaler commits a single-replica scaling action only after the corresponding counter crosses a configurable threshold, and adjusts capacity by one replica at a time. When scaling up, the autoscaler spawns a worker —an OS thread that holds one live Wasmtime component instance for its entire lifetime. Each worker 1

Sourcecode available at https://github.com/Della97/Epico

4

M. Della Bartola et al.

connects two ZMQ sockets: a DEALER socket to its own stage’s dispatcher (from which it pulls events) and a PUSH socket to the subsequent stage’s dispatcher. The Worker loop deserializes each incoming JSON event into a Val::Record, calls the component’s process-event export, serializes the output back to JSON, appends a per-hop timing entry to the event’s benchmark context, and signals readiness back to the dispatcher. When scaling down, the autoscaler sets a drain flag on the target worker; the worker then exits cleanly at the next loop iteration. The Supervisor module manages the dispatcher child processes. It spawns them at startup in a downstream-first order, installs a Ctrl+C handler, and gracefully kills the entire process tree upon shutdown. The Supervisor spawns one Dispatcher process for each stage. The Dispatcher is a single-threaded ZeroMQ broker exposing three sockets: a PULL frontend to receive events from the previous stage, a ROUTER backend to which replicas connect with DEALER sockets, and a REP control socket the autoscaler queries via REQ. The Dispatcher’s primary role is to accept events from the producer, distribute them to ready replicas under a worker-pull dispatch strategy: only replicas that have signaled readiness are eligible to receive events, so the ROUTER pushes events in FIFO order over the ready queue. This is structurally least-loaded without explicit load measurement. Internally, the Dispatcher maintains three data structures. First, an event buffer : a FIFO of pending events received on the frontend. Once it reaches the configured maximum, the dispatcher stops polling the frontend, which propagates backpressure upstream via the PULL socket’s high-water mark rather than dropping events. Second, a ready queue: a FIFO of replica identities representing free dispatch slots, with one entry per credit held: a replica with K credits appears K times. The queue and the per-replica credit count are kept in sync as an invariant: each successful dispatch pops one entry and decrements that replica’s credit count by one; each credit refill pushes K entries and increments credits by K. Third, a worker registry: a hash map keyed by replica identity recording its remaining credit count, its lifetime dispatched-event count, and its most recently reported metric payload. The registry is consulted on every successful send and on every control reply. Replica departure is detected lazily and handled uniformly across causes. When the autoscaler drains a replica, the worker thread exits at its next loop iteration but sends no notification to the dispatcher. The dispatcher therefore has no proactive liveness mechanism and discovers the departure only when its next send_multipart to that identity returns EHOSTUNREACH. This mechanism handles graceful drains and unexpected disappearances indistinguishably, and triggers a bulk cleanup that removes the identity from the registry and evicts all of its remaining credit entries from the ready queue in one O(n) pass. Credit-Based Flow Control. A strict request-reply protocol between dispatcher and worker, equivalent to a credit window of 1, bottlenecks per-worker throughput on the dispatcher to worker round trip, irrespective of how cheap the WebAssembly stage is. To break this bottleneck, Epico implements a credit-based sliding window protocol inspired by TCP flow control, layered on top of the existing DEALERROUTER socket pair between worker and dispatcher. On boot, each worker

Epico: Serverless Stream Processing via Wasm

5

sends a hello message advertising a credit window N ; the dispatcher records this as the worker’s initial credit balance. The dispatcher is then free to send up to N events to that worker without waiting, decrementing the worker’s credit on each send. The worker processes events as they arrive, once it has completed at least N/2 events, sends a single refill message carrying both the latest execution telemetry and the number of credits to replenish. The dispatcher blocks only when all workers in the pool have exhausted their credits. The window amortizes the round-trip between dispatcher and worker across N/2 events at the cost of a tradeoff: backpressure becomes per-window rather than per-event. Delivery is currently best-effort: the event that triggers EHOSTUNREACH is retained and redispatched, but events already in flight to the departed worker are lost. Achieving at-least-once delivery would require a per-worker "recently sent" buffer on the dispatcher that replays unacknowledged events. Workflow to Instantiate a Pipeline. Using the proposed framework, instantiating a pipeline requires only two developer actions and a single CLI invocation. First, the developer writes a pipeline.yaml file describing the record types, stages (with their input/output types, source paths, and scaling parameters), and the edges defining the linear DAG. Second, they provide one Rust file per stage containing the business logic wrapped in the stage! macro. Running Epico build then parses the YAML configuration and generates the target/Epico/ workspace, creating one crate per stage with the corresponding wit/world.wit, src/lib.rs, and runtime.yaml. Each crate is compiled into a WASI-P2 component (.wasm, optionally .cwasm). Finally, Epico run starts the runtime by launching the GrandMaster, which spawns a dispatcher for each stage.

4

Experimental Evaluation

We evaluate Epico along three axes: ablation studies that isolate the impact of individual architectural choices, a comparison between serverless and serverfull deployment with Epico, and a head-to-head comparison against OpenWhisk as a general-purpose serverless platform. Hardware. All benchmark tests were executed on a single x86 machine equipped with an AMD Ryzen 7 5700U processor (8 cores @ 1.8 GHz) and 16 GB of RAM. Workloads. We implemented two stream-processing pipelines designed to ingest synthetically generated IoT sensor data. The Simple Implementation imports no external Rust modules, establishing a baseline for execution overhead. The Complex Implementation imports various external libraries, accurately reflecting the heavier compilation logic of a production-grade application. Baselines and Configurations. For our ablation studies, we evaluated our framework natively by toggling compilation strategies (AOT vs. JIT [7]) and assessing the impact of our credit-based flow control mechanism. For the stateof-the-art comparison, we deployed logically equivalent pipelines in OpenWhisk. We utilized the composition operational mode to mimic a linear pipeline, with each stage executing the exact same Rust code used in our native framework.

6

M. Della Bartola et al.

4.1

Ablation Study

Compilation Strategy. To evaluate the performance gains introduced by our framework’s optimizations, we first isolate the impact of AOT compilation against a baseline JIT compilation. The primary objective is to assess reductions in coldstart latency across both the Simple and Complex implementations. Our results demonstrate that while JIT and AOT deliver identical steadystate performance, JIT introduces a severe latency penalty during cold starts that scales with application complexity. In the Simple Implementation, which imports no external modules, JIT compilation adds approximately 11 ms of overhead per stage (Fig. 2a). Consequently, the maximum end-to-end latency for the JIT pipeline reaches 42 ms, whereas the AOT one only 18 ms (Fig. 4). The performance gap widens drastically in the Complex case. The inclusion of external dependencies raises the JIT compilation time, resulting in first-invocation latencies of 88.0 ms, 15.9 ms, and 53.7 ms across the three pipeline stages (Fig. 2b).

Cold vs warm cold-start latency (Epico - Simple pipeline - P50 annotated) normalize detect finalize

Cold vs warm cold-start latency (Epico - Complex pipeline - P50 annotated) attest denoise featurize 88.0

100 14

11.7

10.9

cold-start latency (ms)

cold-start latency (ms)

12 10 0.6 0.5 0.4 0.3

0.23 0.19

75

10.7

0.19

0.210.19

0.18

0.220.18

0.19

0.2

53.7

50 15.9

25 0.6 0.5 0.4 0.3

0.23 0.19

0.19

0.22 0.19

0.20

0.230.19

0.19

0.2

AOT

cold

JIT

AOT

warm

JIT

p50

AOT

JIT

whisker / outliers

(a) Simple Implementation Cold Start.

AOT

cold

JIT

AOT

warm

JIT

p50

AOT

JIT

whisker / outliers

(b) Complex Implementation Cold Start.

Fig. 2: Cold-start latency comparisons for Compilation Strategies over 20 AOT and 20 JIT runs (The y-axis is split to improve readability).

Credit-Based Flow Control. We next evaluate the throughput gains of our credit-based flow control protocol (Fig.5). For these tests, both the Simple and Complex applications were deployed as linear three-stage pipelines constrained to exactly one worker max replica per stage. In a strict request-reply baseline (a credit window of 1), synchronous telemetry replies bottleneck the dispatcherto-worker IPC. This caps single-worker throughput at 9.7 kev/s for the Simple pipeline and 8.5 kev/s for the Complex pipeline. By implementing a sliding window protocol that permits up to N unacknowledged events in flight, we successfully amortize this round-trip cost. Toggling the credit window to 8 yields noticeable improvements: capacity jumps to 38.8 kev/s (a 4× increase) for the Simple pipeline and 26.0 kev/s (a 3.0× increase) for the Complex pipeline. Further

Epico: Serverless Stream Processing via Wasm

7

Fig. 3: Per stage independent scaling.

increasing the window to 16 and 32 provides marginal gains, plateauing at around 40.0 kev/s and 27.0 kev/s respectively. Beyond N = 8 the bottleneck shifts from the dispatcher-to-worker path to the dispatcher’s single-threaded per-event work. This confirms that a credit window of 8 optimally hides IPC overhead, enabling high-throughput execution that is impossible under a strict request-reply model. 4.2

Performance Comparison

Serverless vs. Serverfull. We compare our framework under a serverless scaling model, where each stage scales independently based on queue depth (Fig. 3), against a serverfull deployment with a static replica allocation. Both configurations were tuned via grid search to achieve the same median end-to-end latency of 1.1 ms (Fig. 4). In the serverfull setup, replicas were fixed at their optimal capacities, whereas the serverless deployment dynamically scaled each stage up to a configured maximum. While delivering equivalent P50 latency, the serverless approach reduced resource consumption by 36.5% in terms of replica-seconds, averaged over 20 runs. These results show that autonomous per-stage autoscaling reclaims idle compute capacity during load troughs without sacrificing typical pipeline latency. OpenWhisk Comparison. We compared our native stream-processing framework against Apache OpenWhisk. While OpenWhisk’s composition mode achieves platform-level concurrency, it does not provide true pipeline parallelism. Stages do not maintain continuous execution; instead, they operate as distinct serverless invocations sequentially coordinated by a central controller. This architecture inherently suffers from an orchestrator bottleneck. Intermediate data must be routed back through the controller before triggering the next stage, preventing direct, high-throughput handoffs. Furthermore, OpenWhisk relies on containerization, which introduces severe cold-start penalties. As observed in our tests, each individual stage incurs nearly 800 ms of initialization during a cold start: 773

8

M. Della Bartola et al. End-to-end latency: serverfull vs serverless (AOT / JIT) (20 runs pooled; n=sf:1,995,043 aot:1,994,057 jit:1,998,101) empirical CDF

100%

serverfull

80%

serverless-AOT

60%

serverless-JIT

p99.9=163 ms p99.9=153 ms p99.9=304 ms p99=6.9 ms p99=34 ms p99=80 ms

40% p50=1.1 ms p50=1.1 ms p50=1.1 ms

20% 0%

101

100

102

end-to-end latency (ms, log scale)

Fig. 4: E2E latency serverfull vs serverless (AoT and JIT). Throughput vs credit window (20 runs each) box = IQR, notch = 95% CI of median, ◆ = event-weighted mean Simple pipeline Complex pipeline 41.5

28.0

Throughput (k events / s)

4.3× range

3.2× range

40.9

41.0

27.2

27.5

40.2

40.5 27.0

40.0 39.5

26.6

26.5

38.8

26.0

39.0 26.0

38.5 38.0 9.8

25.5 8.6

9.6

8.4

9.4

cw = 1

cw = 8

cw = 16

cw = 32

cw = 1

cw = 8

cw = 16

cw = 32

Fig. 5: Throughput comparison across different credit window sizes for the Simple and Complex pipelines. (20 runs each credit window).

ms for normalization, 786 ms for detection, and 781 ms for finalization (Fig. 6a). Cumulatively, this drives the E2E cold-start latency to 3.32 s (Fig. 6b). Even when fully warm, OpenWhisk’s centralized routing overhead inflates the pipeline’s end-to-end latency to 102 ms, resulting in a 32.5× gap between cold and warm states. Beyond latency, OpenWhisk scales these stateless invocations blindly against a global namespace limit. Without per-stage capacity controls, a single slow stage can indiscriminately spawn containers, saturate system resources, and throttle the entire workflow. In contrast, our framework eliminates these structural flaws by utilizing Wasmtime for microsecond-level instantiation, ZeroMQ for direct, broker-free handoffs, and granular limits for stage replication.

5

Related Works

WebAssembly for Serverless. Several works investigate the use of WebAssembly as a lightweight execution environment for serverless functions [15, 11, 8, 2]. Kjorveziroski et al. [12] analyze the performance of popular WebAssembly runtimes in terms of cold start delay and execution time, comparing JIT and AOT compilation. Other works focus on custom runtimes that leverage WebAssembly

Epico: Serverless Stream Processing via Wasm Cold vs warm end-to-end latency (OpenWhisk)

Per-stage container initialization (OpenWhisk) 880

cold init (ms)

840 820 800 786 ms

780

781 ms

773 ms

760 740 720 normalize

detect

finalize

(a) Per-stage init latency.

warm

cold

3500 3400 3.32 s

3300 3200 3100

warm e2e (ms)

cold e2e (ms)

3600

860

9

200

100

102 ms

0 warm (n = 984 invocations)

cold (n = 1000 invocations)

(b) Cold vs warm E2E latency.

Fig. 6: Performance evaluation of the Simple pipeline in OpenWhisk.

for serverless computing at the edge. Hall et al. [11] present a WebAssembly-based serverless runtime for edge environments built on top of Node.js and V8, showing lower cold-start latency compared to container-based deployments. Similarly, addressing serverless at the edge, Gadepalli et al. [9, 10] propose aWsm and Sledge. The former is a WebAssembly runtime that targets edge devices. The latter is a serverless framework built on top of aWsm. It leverages AoT compilation to LLVM to enable low-latency execution and efficient concurrency management on resource-constrained devices. For compute-intensive and distributed workloads, Shillaker et al. [21, 20] introduce Faasm, a distributed serverless runtime based on WebAssembly. Faasm provides lightweight isolation through Faaslets, enabling memory sharing between functions while reducing cold-start overheads through a snapshot-based mechanism. While these works demonstrate the potential of WebAssembly for reducing cold-start overheads and improving execution isolation in serverless environments, they primarily focus on general-purpose FaaS platforms. In contrast, our work investigates WebAssembly for a stream processing serverless runtime, emphasizing low-latency stage-to-stage communication, per-stage autoscaling, and high-throughput workflow execution. Workflow-Oriented Serverless Frameworks. Recent works focus on serverless frameworks for orchestrating workflows and DAG-based applications across cloud, edge, and HPC infrastructures. HyperFlow [16], UniFaaS [13], OSCAR [18], and SCAR [17] focus on scientific workflow orchestration and federated execution across heterogeneous infrastructures, including cloud platforms, accelerators, and HPC systems. Other systems target performance-oriented DAG execution. WUKONG [5] employs decentralized scheduling and task clustering to improve data locality and reduce coordination overheads for burst-parallel workloads on AWS Lambda. Similarly, DataFlower [14] adopts a data-flow execution model to minimize orchestration overheads and improve responsiveness in serverless workflows. In contrast to these works, Epico targets stream processing applications rather than workflow orchestration, and a single host rather than a federated infrastructure. Stages are long-lived consumers of a continuous event stream, autoscaled per stage against queue-depth SLOs, rather than coarse-grained tasks

10

M. Della Bartola et al.

scheduled per invocation by a DAG engine. The current prototype deliberately restricts topologies to linear DAGs and defers fan-out, fan-in to future works. The focus is instead on the runtime mechanics that make wasm stages viable as a serverless execution targeting stream processing. Serverless Stream Processing. To the best of our knowledge, few works specifically target serverless stream processing runtimes. Sponge [22] uses serverless functions to elastically absorb workload bursts in stream-processing pipelines and scale on-demand in case of peak load. However, it primarily acts as an auxiliary elasticity layer for existing stream processing application, whereas our work provides a standalone serverless runtime with native stage-level autoscaling. In contrast, SPSC [4] is conceptually more similar to our work and offers a serverless framework built on top of public FaaS platforms. Our work differentiates from this by not relying on existing general-purpose serverless platform by providing a serverless runtime that manages directly stage scaling, inter-stage (inter-function) communication, and by using WebAssembly as an execution environment.

6

Future Works

Several components of the current prototype represent natural directions for future work. Autoscaling. The current autoscaler relies solely on dispatcher queue depth. Extending it with latency, downstream backpressure, and host resource metrics would improve decisions under diverse workloads. Topology. The prototype currently supports only linear DAGs. Adding fan-in and fan-out would broaden the range of supported stream-processing applications. Distributed execution. While distributed deployment is already possible through manual configuration, future work includes automatic stage placement, transparent transport selection, and host-aware autoscaling. Dynamic workflow adaptation. The execution graph is currently static. Supporting runtime DAG transformations (e.g., stage fusion and scission) and policy- or LLM-driven sub-workflow creation would enable adaptive execution while preserving application semantics.

7

Conclusions

We presented Epico, a serverless stream-processing runtime in which pipelines are long-lived WebAssembly components, scaled independently per stage from zero against queue-depth SLOs, and connected through direct broker-free ZeroMQ channels. We showed that AOT reduces cold-start latency from tens or hundreds of milliseconds to sub-millisecond, and that a credit-based sliding-window protocol between workers and dispatchers raises per-worker throughput by up to 4.2× relative to a strict request–reply baseline. Compared head-to-head with Apache

Epico: Serverless Stream Processing via Wasm

11

OpenWhisk on logically equivalent pipelines, Epico avoids the orchestrator bottleneck and the container-driven cold-start penalty that bound general-purpose FaaS platforms when used for streaming workloads. Acknowledgments. This work has been partially funded by the NOUS (A catalyst for EuropeaN ClOUd Services in the era of data spaces, high-performance and edge computing) HORIZON-CL4-2023-DATA-01-02 project, G.A. n. 101135927, and by Spoke 1 "FutureHPC & BigData" of the Italian Research Center on High-Performance Computing, Big Data and Quantum Computing (ICSC) funded by MUR Missione 4 Componente 2 Investimento 1.4: Potenziamento strutture di ricerca e creazione di "campioni nazionali di R&S (M4C2-19 )" - Next Generation EU (NGEU).

References 1. Besozzi, V., Bartola, M.D., Dazzi, P., Danelutto, M.: High-performance serverless computing: A systematic literature review on serverless for hpc, ai, and big data. IEEE Access 13, 195611–195656 (2025). https://doi.org/10.1109/ACCESS.2025.3633989 2. Besozzi, V., Fiasco, E., Danelutto, M., Dazzi, P.: Webassembly and unikernels: A comparative study for serverless at the edge (2025), https://arxiv.org/abs/2509 .09400 3. Bytecode Alliance: Wasmtime: A webassembly and wasi runtime. https://wasmti me.dev/ (nd) 4. Cai, Z., Chen, Z., Chen, X., Ma, R., Guan, H., Buyya, R.: Spsc: Stream processing framework atop serverless computing for industrial big data. IEEE Transactions on Cybernetics 54(11), 6509–6517 (2024). https://doi.org/10.1109/TCYB.2024.3407886 5. Carver, B., Zhang, J., Wang, A., Anwar, A., Wu, P., Cheng, Y.: Wukong: a scalable and locality-enhanced framework for serverless parallel computing. In: Proceedings of the 11th ACM Symposium on Cloud Computing. p. 1–15. SoCC ’20, Association for Computing Machinery, New York, NY, USA (2020). https://doi.org/10.1145/3419111.3421286, https://doi.org/10.1145/3419111.34 21286 6. Castro, P., Ishakian, V., Muthusamy, V., Slominski, A.: The rise of serverless computing. Commun. ACM 62(12), 44–54 (Nov 2019). https://doi.org/10.1145/3368454, place: New York, NY, USA Publisher: Association for Computing Machinery 7. Colosi, M., Farahani, R., Loven, L., Prodan, R., Villari, M.: Serverless everywhere: A comparative analysis of webassembly workflows across browser, edge, and cloud (2025), https://arxiv.org/abs/2512.04089 8. Gackstatter, P., Frangoudis, P.: Pushing serverless to the edge with webassembly runtimes. pp. 140–149 (05 2022). https://doi.org/10.1109/CCGrid54584.2022.00023 9. Gadepalli, P., Peach, G., Cherkasova, L., Aitken, R., Parmer, G.: Challenges and opportunities for efficient serverless computing at the edge. pp. 261–2615 (10 2019). https://doi.org/10.1109/SRDS47363.2019.00036 10. Gadepalli, P.K., McBride, S., Peach, G., Cherkasova, L., Parmer, G.: Sledge: a serverless-first, light-weight wasm runtime for the edge. In: Proceedings of the 21st International Middleware Conference. p. 265–279. Middleware ’20, Association for Computing Machinery, New York, NY, USA (2020), https://doi.org/10.1145/ 3423211.3425680

12

M. Della Bartola et al.

11. Hall, A., Ramachandran, U.: An execution model for serverless functions at the edge. In: Proceedings of the International Conference on Internet of Things Design and Implementation. pp. 225–236. IoTDI ’19, Association for Computing Machinery, New York, NY, USA (2019). https://doi.org/10.1145/3302505.3310084, event-place: Montreal, Quebec, Canada 12. Kjorveziroski, V., Filiposka, S.: Webassembly as an enabler for next generation serverless computing. Journal of Grid Computing 21 (2023), https://api.semant icscholar.org/CorpusID:259246945 13. Li, Y., Chard, R., Babuji, Y., Chard, K., Foster, I., Li, Z.: Unifaas: Programming across distributed cyberinfrastructure with federated function serving. In: 2024 IEEE International Parallel and Distributed Processing Symposium (IPDPS). pp. 217–229 (2024). https://doi.org/10.1109/IPDPS57955.2024.00027 14. Li, Z., Xu, C., Chen, Q., Zhao, J., Chen, C., Guo, M.: Dataflower: Exploiting the data-flow paradigm for serverless workflow orchestration. In: Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 4. p. 57–72. ASPLOS ’23, Association for Computing Machinery, New York, NY, USA (2024). https://doi.org/10.1145/3623278.3624755 15. Long, J., Tai, H.Y., Hsieh, S.T., Yuan, M.J.: A Lightweight Design for Serverless Function as a Service. IEEE Software 38(1), 75–80 (2021). https://doi.org/10.1109/MS.2020.3028991 16. Malawski, M., Gajek, A., Zima, A., Balis, B., Figiela, K.: Serverless execution of scientific workflows: Experiments with hyperflow, aws lambda and google cloud functions. Future Generation Computer Systems 110, 502–514 (2020). https://doi.org/https://doi.org/10.1016/j.future.2017.10.029 17. Pérez, A., Moltó, G., Caballer, M., Calatrava, A.: Serverless computing for container-based architectures. Future Generation Computer Systems 83, 50– 59 (2018). https://doi.org/https://doi.org/10.1016/j.future.2018.01.022, https: //www.sciencedirect.com/science/article/pii/S0167739X17316485 18. Pérez, A., Risco, S., Naranjo, D.M., Caballer, M., Moltó, G.: On-premises serverless computing for event-driven data processing applications. In: 2019 IEEE 12th International Conference on Cloud Computing (CLOUD). pp. 414–421 (2019). https://doi.org/10.1109/CLOUD.2019.00073 19. Rossberg, A.: WebAssembly Core Specification (2019), https://www.w3.org/TR/ wasm-core-1/ 20. Segarra, C., Shillaker, S., Li, G., Mappoura, E., Bruno, R., Vilanova, L., Pietzuch, P.: GRANNY: Granular management of Compute-Intensive applications in the cloud. In: 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI 25). pp. 205–218. USENIX Association, Philadelphia, PA (Apr 2025), https: //www.usenix.org/conference/nsdi25/presentation/segarra 21. Shillaker, S., Pietzuch, P.: Faasm: Lightweight Isolation for Efficient Stateful Serverless Computing. In: 2020 USENIX Annual Technical Conference (USENIX ATC 20). pp. 419–433. USENIX Association (Jul 2020), \url{https://www.usenix.org /conference/atc20/presentation/shillaker} 22. Song, W.W., Um, T., Elnikety, S., Jeon, M., Chun, B.G.: Sponge: Fast reactive scaling for stream processing with serverless frameworks. In: USENIX ATC 23. pp. 301–314. USENIX Association, Boston, MA (Jul 2023), https://www.usenix.org /conference/atc23/presentation/song 23. WebAssembly Community Group: WebAssembly System Interface (Feb 2020), https://github.com/WebAssembly/WASI/blob/d8b286c697364d8bc4daf1820b2 5a9159de364a3/phases/snapshot/docs.md

Related documents

• Vivace: Exact Temporal OLAP over Interval Histories via Independent Serverless Execution#271781
• UPC++: A High-Performance Communication Framework for Asynchronous Computation#814595
• FlashEvolve: Accelerating Agent Self-Evolution with Asynchronous Stage Orchestration#175230
• CVE-2026-73494 — HIGH 7.4#923936
• ContextWeave: A Real-World Workflow Benchmark#429407