Modern network infrastructures increasingly rely on Software-Defined Networking (SDN) and Network Function Virtualisation (NFV) to achieve flexibility, scalability, and efficiency. While these paradigms facilitate the deployment of Cloud-native Network Functions (CNF), they lack tools for high-level programming and guarantees on correct multi-component compositions. We introduce Choreography-Defined Networking (CDN), a methodology that applies choreographic programming to the specification and implementation of SDN compositions. In CDN, developers write a single global choreography that describes interactions among CNFs and a compiler generates endpoint code that coordinate them as specified in the choreography. CDN delivers correctness-by-construction guarantees – including deadlock freedom and communication-type safety – while eliminating the need for a centralised orchestrator, replaced by direct, parallel communication among CNFs. To evaluate our methodology, we use CDN to design and implement a case study on a distributed, AI-enhanced SDN composition for volumetric attack detection and mitigation, in which four CNFs collaboratively analyse traffic using volumetric anomaly inspection, machine-learning classification, and signature matching. We compare this CDN implementation against two SDN baselines: a classical controller-driven chain and a hybrid solution that repurposes network traffic as a management channel. Experiments across four representative attack scenarios show that the CDN approach reduces mean decision latency by approximately 15% over both baselines, while generating up to 80% less management traffic. These results confirm that CDN allows to raise the abstraction level at which one writes distributed SDN compositions without compromising – actually improving – runtime performance in real-world network deployments.

The Function-as-a-Service (FaaS) paradigm offers a serverless approach that abstracts the management of underlying infrastructure, enabling developers to focus on application logic. However, leveraging infrastructure-aware features can further optimize serverless performance. We present a software prototype that enhances Apache OpenWhisk serverless platform with a novel architecture incorporating tAPP (topology-aware Allocation Priority Policies), a declarative language designed for specifying topology-aware scheduling policies. Through a case study involving distributed data access across multiple cloud regions, we show that tAPP can significantly reduce latency and minimizes performance variability compared to the standard OpenWhisk implementation.

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.

Serverless computing has extended its reach to encompass private edge cloud systems, aiming to enhance latency, security, and privacy while optimising resource usage. However, this extension comes with challenges such as running platforms and functions on disparate and resource-constrained devices. To respond to the challenges, we present FunLess, a Function-as-a-Service (FaaS) platform tailored for private edge cloud systems. Unlike conventional solutions relying on container technologies for function invocation, FunLess leverages WebAssembly (Wasm) as its runtime environment. This choice offers several advantages, including inherent security and isolation mechanisms crucial for data integrity and confidentiality, portability and consistent development and deployment, and a reduced memory footprint that allows functions to run on constrained edge devices.

Meta-solver approaches exploit many individual solvers to potentially build a better solver. To assess the performance of meta-solvers, one can adopt the metrics typically used for individual solvers (e.g., runtime or solution quality) or employ more specific evaluation metrics (e.g., by measuring how close the meta-solver gets to its virtual best performance). In this paper, based on some recently published works, we provide an overview of different performance metrics for evaluating (meta-)solvers by exposing their strengths and weaknesses.

State-of-the-art serverless platforms use hard-coded scheduling policies that are unaware of the possible topological constraints of functions. Considering these constraints when scheduling functions leads to sensible performance improvements, e.g., minimising loading times or data-access latencies. This issue becomes more pressing when considered in the emerging multi-cloud and edge-cloud-continuum systems, where only specific nodes can access specialised, local resources. To address this problem, we present a declarative language for defining serverless scheduling policies to express constraints on topologies of schedulers and execution nodes. We implement our approach as an extension of the OpenWhisk platform.

SUNNY is a k-nearest neighbors based Algorithm Selection (AS) approach that schedules and runs a number of solvers for a given unforeseen problem. In this work we present sunny-as2, an enhancement of SUNNY for generic AS scenarios that advances the original approach with wrapper-based feature selection, neighborhood-size configuration and a greedy approach to speed-up the training phase. Empirical evidence shows that sunny-as2 is competitive w.r.t. state-of-the-art AS approaches.

SUNNY is an Algorithm Selection (AS) technique originally tailored for Constraint Programming (CP). SUNNY is based on the k-nearest neighbors algorithm and enables one to schedule, from a portfolio of solvers, a subset of solvers to be run on a given CP problem. This approach has proved to be effective for CP problems. In 2015, the ASlib benchmarks were released for comparing AS systems coming from disparate fields (e.g., ASP, QBF, and SAT) and SUNNY was extended to deal with generic AS problems. This led to the development of sunny-as, a prototypical algorithm selector based on SUNNY for ASlib scenarios. A major improvement of sunny-as, called sunny-as2, was then submitted to the Open Algorithm Selection Challenge (OASC) in 2017, where it turned out to be the best approach for the runtime minimization of decision problems. In this work we present the technical advancements of sunny-as2, by detailing through several empirical evaluations and by providing new insights. Its current version, built on the top of the preliminary version submitted to OASC, is able to outperform sunny-as and other state-of-the-art AS methods, including those who did not attend the challenge.

Highly-configurable software systems can have thousands of interdependent configuration options across different subsystems. In the resulting configuration space, discovering a valid product configuration for some selected options can be complex and error prone. The configuration space can be organized using a feature model, fragmented into smaller interdependent feature models reflecting the configuration options of each subsystem.

Microservices are highly modular and scalable Service Oriented Architectures. They underpin automated deployment practices like Continuous Deployment and Autoscaling. In this paper we formalize these practices and show that automated deployment — proven undecidable in the general case — is algorithmically treatable for microservices. Our key assumption is that the configuration life-cycle of a microservice is split into two phases: (i) creation, which entails establishing initial connections with already available microservices, and (ii) subsequent binding/unbinding with other microservices. To illustrate the applicability of our approach, we implement an automatic optimal deployment tool and compute deployment plans for a realistic microservice architecture, modeled in the Abstract Behavioral Specification (ABS) language.

Software Product Lines (SPLs) are a common technique to capture families of software products in terms of commonalities and variabilities. On a conceptual level, functionality of an SPL is modeled in terms of features in Feature Models (FMs). As other software systems, SPLs and their FMs are subject to evolution that may lead to the introduction of anomalies (e.g., non-selectable features). To fix such anomalies, developers need to understand the cause for them. However, for large evolution histories and large SPLs, explanations may become very long and, as a consequence, hard to understand. In this paper, we present a method for anomaly detection and explanation that, by encoding the entire evolution history, identifies the evolution step of anomaly introduction and explains which of the performed evolution operations lead to it. In our evaluation, we show that our method significantly reduces the complexity of generated explanations.

Abstract In Constraint Programming, a portfolio solver combines a variety of different constraint solvers for solving a given problem. This fairly recent approach enables to significantly boost the performance of single solvers, especially when multicore architectures are exploited. In this work, we give a brief overview of the portfolio solversunny-cp, and we discuss its performance in the MiniZinc Challenge—the annual international competition for Constraint Programming solvers—where it won two gold medals in 2015 and 2016.

The problem of deploying a complex software application has been formally investigated in previous work by means of the abstract component model named Aeolus. As the problem turned out to be undecidable, simplified versions of the model were investigated in which decidability was restored by introducing limitations on the ways components are described. In this paper, we take an opposite approach, and investigate the possibility to address a relaxed version of the deployment problem without limiting the expressiveness of the component model. We identify three problems to be solved in sequence: (i) the verification of the existence of a final configuration in which all the constraints imposed by the single components are satisfied, (ii) the generation of a concrete configuration satisfying such constraints, and (iii) the synthesis of a plan to reach such a configuration possibly going through intermediary configurations that violate the non-functional constraints.

Given a collection of algorithms, the Algorithm Selection (AS) problem consists in identifying which of them is the best one for solving a given problem. The selection depends on a set of numerical features that characterize the problem to solve. In this paper we show the impact of feature selection techniques on the performance of the SUNNY algorithm selector, taking as reference the benchmarks of the AS library (ASlib). Results indicate that a handful of features is enough to reach similar, if not better, performance of the original SUNNY approach that uses all the available features. We also present sunny-as: a tool for using SUNNY on a generic ASlib scenario.

Abstract Within the context of constraint solving, a portfolio approach allows one to exploit the synergy between different solvers in order to create a globally better solver. In this paper we present SUNNY: a simple and flexible algorithm that takes advantage of a portfolio of constraint solvers in order to compute — without learning an explicit model — a schedule of them for solving a given Constraint Satisfaction Problem (CSP). Motivated by the performance reached by SUNNY vs. different simulations of other state of the art approaches, we developedsunny-csp, an effective portfolio solver that exploits the underlying SUNNY algorithm in order to solve a given CSP. Empirical tests conducted on exhaustive benchmarks of MiniZinc models show that the actual performance ofsunny-cspconforms to the predictions. This is encouraging both for improving the power of CSP portfolio solvers and for trying to export them to fields such as Answer Set Programming and Constraint Logic Programming.

Cloud computing offers the possibility to build sophisticated software systems on virtualized infrastructures at a fraction of the cost necessary just a few years ago. Nevertheless, the deployment of such complex systems is a serious issue due to the large number of involved software packages and services, and to their elaborated interdependencies. In this paper we address the challenge of automatizing this complex deployment process. We first formalize it as a planning problem and observe that standard planning tools can effectively solve it only on small and trivial instances. For this reason, we propose an ad hoc planning technique which we validate by means of a prototype implementation able to effectively solve this deployment problem also on instances of realistic size.

Abstract We study the decidability of termination for two CHR dialects which, similarly to the Datalog like languages, are defined by using a signature which does not allow function symbols (of arity > 0). Both languages allow the use of the = built-in in the body of rules, thus are built on a host language that supports unification. However each imposes one further restriction. The first CHR dialect allows onlyrange-restrictedrules, that is, it does not allow the use of variables in the body or in the guard of a rule if they do not appear in the head. We show that the existence of an infinite computation is decidable for this dialect. The second dialect instead limits the number of atoms in the head of rules to one. We prove that in this case, the existence of a terminating computation is decidable. These results show that both dialects are strictly less expressive1than Turing Machines. It is worth noting that the language (without function symbols) without these restrictions is as expressive as Turing Machines.

Constraint Handling Rules (CHR) is a committed-choice declarative language which has been originally designed for writing constraint solvers and which is nowadays a general purpose language.