Jul 2026· International Conference on Future Internet of Things and Cloud· pp. 9-14· 0 citations· 15 references
Abstract
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.
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.
A comprehensive review of Kubernetes scheduling strategies published between January 2023 and January 2026 is presented and a multi-dimensional taxonomy is established that categorizes scheduling approaches based on common objectives, modification methods, optimization methodologies, targeted workloads, evaluation methods, scheduling scopes, and performance metrics.
Mohammed Alhakimi, R. Latip· De Computis· 0 citations
This study compares the implementation of the same backend system, Node.js/Express and MariaDB, in a monolithic and microservices architecture with the same Docker resource allocation, 2 CPUs and 512 MB RAM per architecture, except database containers.
Yoga Ari Tofan· JUTI: Jurnal Ilmiah Teknolog...· 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
Relevance
. The development of V2X systems and the migration of computing toward edge and fog nodes require containerization and orchestration mechanisms; however, the overhead introduced by the orchestration platform itself can reduce the benefit of distributed service placement and is particularly important for resource-constrained infrastructure.
The aim of the study
is to estimate the resource cost of using KubeEdge on top of K3s under an identical microservice workload that emulates V2X message processing and to establish a baseline for subsequent evaluation of service placement algorithms.
Methods.
A review and systematization of current microservice approaches to V2X, edge, and fog computing were carried out. K3s and K3s + KubeEdge configurations were experimentally compared on the same cloud VPS with unchanged hardware resources, software environment, and five workload profiles from idle to stress. Each profile was executed three times and the obtained results were averaged. CPU utilization, RAM consumption, network traffic, request counts, and the 95th and 99th latency percentiles were measured.
Results
. Adding KubeEdge increased RAM consumption by approximately 95–105 MB, or 6–8 % relative to K3s. Differences in CPU utilization, network traffic, and latency were minor; the increase in p95/p99 under high load occurred in both configurations and was primarily associated with node saturation.
Novelty.
The study separately evaluates the platform overhead of KubeEdge while keeping the V2X-oriented application workload unchanged.
Practical significance
. The obtained baseline can be used in further experiments to compare fixed and adaptive microservice placement in a distributed cloud–edge environment and to distinguish the application-level effect of balancing algorithms from orchestration overhead.
Unknown authors· Proceedings of Telecommunica...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
