Searcharxiv⌕ Search

arXiv subjects

Giuseppe De Palma

Publications and source records attributed to Giuseppe De Palma.

9 recordsLinked to original sources

Adaptable TeaStore

Modern cloud-native systems require adapting dynamically to changing operational conditions, including service outages, traffic surges, and evolving user requirements. While existing benchmarks provide valuable testbeds for performance and scalability evaluation, they lack explicit support for studying adaptation mechanisms, reconfiguration strategies, and graceful degradation. These limitations hinder systematic research on self-adaptive architectures in realistic cloud environments. To cover this gap, we introduce Adaptable TeaStore, an extension of the renowned TeaStore architecture that incorporates adaptability as a first-class design concern. Our extension distinguishes between mandatory and optional services, supports multiple component versions -- with varying resource requirements and functionality levels -- considers the outsourcing of functionalities to external providers, and provides local cache mechanisms for performance and resilience. These features enable the systematic exploration of reconfiguration policies across diverse operational scenarios. We discuss a broad catalogue of reference adaptation scenarios centred around Adaptable TeaStore, useful to evaluate the ability of a given adaptation technology to address conditions such as component unavailability, cyberattacks, provider outages, benign/malicious traffic increases, and user-triggered reconfigurations. Moreover, we present an open-source implementation of the architecture with APIs for metrics collection and adaptation triggers, to enable reproducible experiments.

cs.DC↗

Adaptable TeaStore: A Choreographic Approach

The Adaptable TeaStore has recently been proposed as a reference model for adaptable microservice architectures. It includes different configurations, as well as scenarios requiring to transition between them. We describe an implementation of the Adaptable TeaStore based on AIOCJ, a choreographic language that allows one to program multiparty systems that can adapt at runtime to different conditions. Following the choreographic tradition, AIOCJ ensures by-construction correctness of communications (e.g., no deadlocks) before, during, and after adaptation. Adaptation is dynamic, and the adaptation scenarios need to be fully specified only at runtime. Using AIOCJ to model the Adaptable TeaStore, we showcase the strengths of the approach and its current limitations, providing suggestions for future directions for refining the paradigm (and the AIOCJ language, in particular), to better align it with real-world Cloud architectures.

cs.PL↗

Proceedings First Workshop on Adaptable Cloud Architectures

This volume contains the post-proceedings of the Workshop on Adaptable Cloud Architectures (WACA 2025), held on June 20, 2025, in Lille, France, co-located with DisCoTec 2025 - 20th International Federated Conference on Distributed Computing Techniques.

cs.SE↗

Affinity-aware Serverless Function Scheduling

Functions-as-a-Service (FaaS) is a Serverless Cloud paradigm where a platform manages the scheduling (e.g., resource allocation, runtime environments) of stateless functions. Recent work proposed using domain-specific languages to express per-function policies, e.g., policies that enforce the allocation on nodes that enjoy lower latencies to databases and services used by the function. Here, we focus on affinity-aware scenarios, i.e., where, for performance and functional requirements, the allocation of a function depends on the presence/absence of other functions on nodes. We present aAPP, an extension of a declarative, platform-agnostic language that captures affinity-aware scheduling at the FaaS level. We implement an aAPP-based prototype on Apache OpenWhisk. Besides proving that a FaaS platform can capture affinity awareness using aAPP and improve performance in affinity-aware scenarios, we use our prototype to show that aAPP imposes no noticeable overhead in scenarios without affinity constraints.

cs.DC↗

On the Complexity of Reachability Properties in Serverless Function Scheduling

Functions-as-a-Service (FaaS) is a Serverless Cloud paradigm where a platform manages the execution scheduling (e.g., resource allocation, runtime environments) of stateless functions. Recent developments demonstrate the benefits of using domain-specific languages to express per-function scheduling policies, e.g., enforcing the allocation of functions on nodes that enjoy low data-access latencies thanks to proximity and connection pooling. We present aAPP, an affinity-aware extension of a platform-agnostic function scheduling language. We formalise its scheduling semantics and then study the complexity of statically checking reachability properties, e.g., useful to verify that trusted and untrusted functions cannot be co-located. Analysing different fragments of aAPP, we show that checking reachability of policies without affinity has linear complexity, while affinity makes the problem PSpace.

cs.DC↗

Towards a Function-as-a-Service Choreographic Programming Language: Examples and Applications

Choreographic Programming (CP) is a language paradigm whereby software artefacts, called choreographies, specify the behaviour of communicating participants. CP is famous for its correctness-by-construction approach to the development of concurrent, distributed systems. In this paper, we illustrate FaaSChal, a proposal for a CP language tailored for the case of serverless Function-as-a-Service (FaaS). In FaaS, developers define a distributed architecture as a collection of stateless functions, leaving to the serverless platform the management of deployment and scaling. We provide a first account of a CP language tailored for the FaaS case via examples that present some of its relevant features, including projection. In addition, we showcase a novel application of CP. We use the choreography as a source to extract information on the infrastructural relations among functions so that we can synthesise policies that strive to minimise their latency while guaranteeing the respect of user-defined constraints.

cs.PL↗

FunLess: Functions-as-a-Service for Private Edge Cloud Systems

We present FunLess, a Function-as-a-Service (FaaS) platform tailored for the private edge cloud system. FunLess responds to recent trends that advocate for extending the coverage of serverless computing to private edge cloud systems and enhancing latency, security, and privacy while improving resource usage. Unlike existing solutions that rely on containers for function invocation, FunLess leverages WebAssembly (Wasm) as its runtime environment. Wasm's lightweight, sandboxed runtime is crucial to have functions run on constrained devices at the edge. Moreover, the advantages of using Wasm in FunLess include a consistent development and deployment environment for users and function portability (write once, run everywhere) We validate FunLess under different deployment scenarios, characterised by the presence/absence of constrained-resource devices (Raspberry Pi 3B+) and the (in)accessibility of container orchestration technologies - Kubernetes. We compare FunLess with three production-ready, widely adopted open-source FaaS platforms - OpenFaaS, Fission, and Knative. Our benchmarks confirm that FunLess is a proper solution for FaaS private edge cloud systems since it achieves performance comparable to the considered FaaS alternatives while it is the only fully-deployable alternative on constrained-resource devices, thanks to its small memory footprint.

cs.DC↗

Serverless Scheduling Policies based on Cost Analysis

Current proprietary and open-source serverless platforms follow opinionated, hardcoded scheduling policies to deploy the functions to be executed over the available workers. Such policies may decrease the performance and the security of the application due to locality issues (e.g., functions executed by workers far from the databases to be accessed). These limitations are partially overcome by the adoption of APP, a new platform-agnostic declarative language that allows serverless platforms to support multiple scheduling logics. Defining the "right" scheduling policy in APP is far from being a trivial task since it often requires rounds of refinement involving knowledge of the underlying infrastructure, guesswork, and empirical testing. In this paper, we start investigating how information derived from static analysis could be incorporated into APP scheduling function policies to help users select the best-performing workers at function allocation. We substantiate our proposal by presenting a pipeline able to extract cost equations from functions' code, synthesising cost expressions through the usage of off-the-shelf solvers, and extending APP allocation policies to consider this information.

cs.PL↗

Topology-aware Serverless Function-Execution Scheduling

Cloud-edge serverless applications or serverless deployments spanning multiple regions introduce the need to govern the scheduling of functions to satisfy their functional constraints or avoid performance degradation. For instance, functions may require to be allocated to specific private (edge) nodes that have access to specialised resources or to nodes with low latency to access a certain database to decrease the overall latency of the application. State-of-the-art serverless platforms do not support directly the implementation of topological constraints on the scheduling of functions. We address this problem by presenting a declarative language for defining topology-aware, function-specific serverless scheduling policies, called tAPP. Given a tAPP script, a compatible serverless scheduler can enforce different, co-existing topological constraints without requiring ad-hoc platform deployments. We prove our approach feasible by implementing a tAPP-based serverless platform as an extension of the Apache OpenWhisk serverless platform. We show that, compared to vanilla OpenWhisk, our extension does not negatively impact the performance of generic, non-topology-bound serverless scenarios, while it increases the performance of topology-bound ones.

cs.DC↗