This work introduces 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, and lets system administrators swap the WASM runtime and the datastore to fit available resources and application requirements, without altering application code.
Abstract
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.
Function-as-a-Service (FaaS) is a widely adopted paradigm to simplify application deployment across the edge-to-cloud continuum. However, its stateless nature forces functions to retrieve their state from external, typically cloud-centric, data stores, reintroducing the very latency that edge computing aims to eliminate. This issue is further exacerbated by location-agnostic schedulers and rigid, one-size-fits-all consistency models that fail to capture the diverse requirements of edge applications. In this paper, we propose Ermes, a distributed platform that natively integrates state management into the FaaS paradigm, enabling the joint distribution of computational workloads and application state across the edge-to-cloud continuum. Ermes organizes application state into logical units, termed collections, and employs a distributed coordination algorithm that jointly maps collections and functions onto the available nodes seeking to minimize the latency perceived by the clients. In addition, it supports fine-grained replication and per-collection consistency levels, ranging from sequential to eventual consistency, leaving developers the choice of how to resolve the trade-off between consistency and performance. The experimental evaluation shows that Ermes quickly turns remote state accesses into local ones and sustains low latency as the workload grows, and as clients move across the edge.
Matteo Cenzato, Dario d'Abate, Arianna Dragoni et al.· 0 citations
Cloud-based applications require architectures that can maintain efficient application loading and performance as workload increases. This study developed and experimentally evaluated three functionally equivalent e-commerce implementations: Monolithic, Baseline Microservices, and Proposed Microservices architectures. An experimental research methodology was adopted, with the same business logic, database, and workload scenarios maintained across the implementations. The Proposed architecture integrated Docker, Kubernetes on Amazon Elastic Kubernetes Service (EKS), horizontal pod autoscaling, load balancing, Redis caching, and CloudFront delivery. Controlled workloads were generated using k6, and performance was assessed using startup time, deployment availability, response time, throughput, autoscaling, resource utilisation, inter-service latency, full user-journey performance, cache effectiveness, and frontend loading metrics. Results showed that the Monolithic architecture had the shortest startup time (1.33 s), while the Proposed architecture required 25.36 s. Under 2,000 virtual users, however, the Proposed architecture achieved an average response time of 33.47 ms and throughput of 1,915.78 req/s, compared with 1,951.56 ms and 670.13 req/s for the Monolithic architecture. The Proposed architecture also recorded 0.00% deployment failure, scaled from 2 to 15 replicas, and reduced cache latency by 30.12% (p = 0.0001). Its frontend FCP (First Contentful Paint), LCP (Largest Contentful Paint) and TTI (Time to Interactive) were each 617 ms. The findings demonstrate that integrated cloud-native mechanisms can substantially improve application performance and scalability under increasing workloads.
Ikediego Henrietta Onyinyechi, A. Godspower, Chekwube Georgina Nwankwo et al.· International journal of re...· 0 citations
Serverless computing has emerged as a compelling cloud paradigm due to its simplified development model, automatic scalability, and fine-grained billing. While its stateless execution model enables high elasticity and resource efficiency, it poses noteworthy challenges for building complex stateful applications. To bridge this gap, modern serverless platforms rely on external cloud storage systems to manage persistent state, giving rise to stateful serverless computing. However, this decoupled architecture introduces two fundamental limitations: performance bottlenecks caused by frequent remote state accesses, and state reliability issues stemming from function crash retries. We propose Arcus, a high-performance function state I/O system co-designed for both idempotent execution and low-latency access. Arcus integrates two key techniques: CFLog, a coordination-free logging mechanism that eliminates internal ordering overhead while ensuring idempotent function execution, and FCCache, a cache system optimized for the dispersed invocation pattern of serverless workloads, which reduces read/write latency by improving local hit rates for reads and shortening the write path. Compared to the state-of-the-art system Halfmoon, Arcus reduces read/write latency by 80.4% and 87.9%, respectively. In evaluations using three real-world applications, Arcus achieves an average 60.3% reduction in end-to-end request latency, demonstrating its effectiveness for fast and reliable function state I/O.
Yijie Liu, Zhuo Huang, Han-Xiang Huang et al.· IEEE Transactions on Paralle...· 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
The analysis of performance has shown that the proposed solution is much better in terms of throughput, latency and fault isolation than the conventional architectures, proving that microservices architecture with proper design presents a solid base of scalable data-intensive systems.
S. Rahman· International Journal of App...· 0 citations
Traditional cluster-based ETL architectures impose a structural tax on data engineering organisations: fixed compute resources provisioned for peak demand, scheduled batch cycles that introduce latency regardless of downstream urgency, and operational overhead that redirects engineering capacity from pipeline design to cluster maintenance. AWS serverless services Lambda, Glue, Step Functions, and Kinesis address this tax by decoupling compute from provisioning, enabling pipelines that execute in response to events, scale automatically with workload demand, and charge only for resources consumed. Python, with native Lambda runtime support and an ecosystem that spans Pandas, PySpark, and the AWS SDK for Pandas, has become the primary implementation language for serverless ETL logic at an enterprise scale. This article examines the engineering decisions that determine whether that architectural promise translates into operational reality. The analysis covers Lambda’s execution model and its hard constraints, Glue’s managed Spark environment and its cost engineering implications, Step Functions orchestration patterns, S3-native data lake architecture, cost optimization strategies, security and governance controls, and real-time processing patterns. The central argument is that serverless ETL does not simplify data engineering; it redistributes engineering effort from infrastructure management to execution model design. Lambda timeout decomposition, cold start management, Glue worker right-sizing, IAM role scoping, and Step Functions state machine cost design are not configuration afterthoughts; they are first-class engineering decisions with direct consequences for pipeline reliability, cost, and compliance readiness. The analysis draws on the practitioner perspective of a data engineer with extensive experience building ETL pipelines in regulated financial services and healthcare environments where infrastructure decisions carry audit consequences.
Rambabu Bolineni· East African Journal of Info...· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
