Jun 2026· IEEE Conference on Network Softwarization· pp. 483-489· 0 citations· 17 references
Computer Science
Abstract
WebAssembly (Wasm) is often presented as a lightweight alternative to containers, especially for serverless edge deployments. In practice, orchestration overhead can dominate startup and runtime efficiency on resource-constrained nodes. We evaluate this overhead on a two-node Raspberry Pi 4 cluster across three lightweight Kubernetes distributions (K3s, K0s, KubeEdge), two Wasm orchestration frameworks (SpinKube, wasmCloud), Knative, and native Kubernetes containers. The evaluation combines end-to-end startup measurements with CPU and memory telemetry in two scenarios: deployment and loaddriven scaling. Across the tested configurations and workloads, native container orchestration provides the lowest overall overhead and the shortest startup times for complete applications. Empirical results demonstrate that binary compilation times for AI-based Wasm components reach up to 18 seconds on edge devices. This effectively neutralizes the technology's theoretical cold-start advantage and causes traditional containers to consistently outperform Wasm in end-to-end startup latency. The results also show that orchestration behavior is strongly affected by autoscaling support, runtime integration choices, and platform-specific constraints.
This paper presents a systematic, practice-driven evaluation of WebAssembly (WASM) as an execution substrate for cloud-native workloads orchestrated through Docker and Kubernetes using runwasi. We develop a reproducible workflow that compiles Rust and Go/TinyGo applications to WASM modules, applies Ahead-of-Time (AOT) optimizations per engine and architecture, and packages minimal OCI artifacts for multi-architecture deployment (amd64, arm64, riscv64). Through controlled experiments on heterogeneous nodes, we benchmark eight CPU-bound workloads, reporting mean, median, and confidence intervals to ensure statistical robustness. The results show that WASM achieves latencies close to native on amd64/arm64, with WasmEdge leading under AOT and Wasmtime offering strong compatibility and stability. Artifact sizes are substantially smaller than traditional containers, improving pull times and packing density. While riscv64 execution is feasible, it remains less mature and more sensitive to engine and build choices. Overall, the findings demonstrate that WASM is a viable and efficient option for Cloud Continuum environments when deployments rely on AOT-optimized artifacts, RuntimeClass-based scheduling, and workloads aligned with the WASI feature set supported by the selected engines.
Álvaro Vázquez-Rodríguez, David Vila-Pérez, Carlos Giraldo-Rodíguez et al.· International Conference on...· 0 citations
This paper addresses the problem of hosting a large number of lightweight Node.js applications on a single server in situations where full-scale container orchestration (Kubernetes, Docker Swarm) introduces excessive overhead. A process-level orchestration approach is proposed in which each application runs as a separate operating system process managed by a single application server implemented in Kotlin with Spring Boot. The paper describes the architecture of the Node Orchestrator system, including a REST API for deployment, a reverse-proxy mechanism, automatic restart of crashed processes, and an automated monitoring module: anomaly detection in process metrics based on the Isolation Forest algorithm for preemptive restarts, and adaptive cooldown management based on failure history. The experiments demonstrate that the prototype works correctly and consumes fewer resources than the container-based approach. The results suggest that process-level orchestration combined with automated monitoring components can serve as a practical alternative for hosting small Express.js services.
F. A. Desyatirikov· PROGRAMMNAYA INGENERIA· 0 citations
WebAssembly (WASM) is emerging as a lightweight alternative to containers for Function-as-a-Service (FaaS) across the edge-cloud continuum. However, existing WASM-based serverless platforms are tightly coupled to specific execution engines and predominantly designed for stateless workloads. This clashes with the heterogeneity of edge deployments, which demand support for stateful applications under diverse hardware and workload constraints. We introduce WASP, a configurable framework that brings stateful serverless execution to the edge-cloud continuum. By abandoning monolithic architectures in favor of strictly decoupled, pluggable components, WASP lets system administrators swap the WASM runtime and the datastore to fit available resources and application requirements, without altering application code. Configurable lifecycle and caching policies further enable fine-tuning for diverse non-functional requirements. Our experimental evaluation demonstrates that WASP introduces negligible runtime overhead and, by swapping runtimes, datastores, and policies, exposes radically different memory and latency profiles, confirming its adaptability to the heterogeneous constraints of the edge-cloud continuum.
Matteo Cenzato, Dario d'Abate, Arianna Dragoni et al.· 0 citations
: Container runtimes serve as the foundational layer responsible for the execution and lifecycle management of containers within Kubernetes clusters. While Docker was historically the default runtime, the introduction of the Container Runtime Interface (CRI) has enabled alternative runtimes such as containerd and CRI-O to become first-class citizens in Kubernetes environments. This paper presents a comparative performance analysis of containerd and CRI-O, the two most widely adopted CRI-compliant runtimes, across several critical operational dimensions. The experimental evaluation encompasses container lifecycle operations including creation, start, stop, and deletion times, image pull performance under varying cache conditions, CPU and memory resource utilization during both idle and load scenarios, and pod startup latency in multi-node cluster configurations. The test environment consists of a Kubernetes v1.34 cluster deployed on three identical bare-metal nodes running Ubuntu 26.04 LTS. Results indicate that CRI-O demonstrates marginally faster container creation times due to its lightweight design optimized specifically for Kubernetes, while containerd exhibits superior image caching performance and broader ecosystem compatibility. Both runtimes show comparable memory footprints under sustained workloads. The findings provide practical guidance for infrastructure engineers selecting container runtimes based on specific performance requirements and operational constraints.
Sava Stanišić, Borislav Đorđević, Branislav Belotic et al.· SINTEZA· 0 citations
While serverless computing is popular, its dominant Function-as-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\times\). Compared to Apache OpenWhisk, Epico bypasses the orchestrator bottlenecks and container overheads that typically hinder FaaS streaming workloads.
Matteo Della Bartola, Valerio Besozzi, Patrizio Dazzi et al.· 0 citations
This paper explores the integration of Spring Boot with containerization and observability, focusing on best practices, architectural patterns, and challenges, and delves into containerization strategies using Docker and orchestration with Kubernetes, emphasizing their roles in deployment and scalability.
Youssef- Al-Habib, Omar Sullaiman· International Journal of Art...· 1 citation