The growing environmental impact of the ICT sector calls for sustainable computing, including software services designed to minimise their carbon footprint, without compromising on quality of service. In particular, software services should be carbon-aware by design - leveraging alternative configurations to reduce emissions while featuring the required quality of service. In this work, we present a carbon-aware approach to realise dynamically adaptive software services. We propose an optimisation scheme that enables serving incoming requests with different implemented versions of software services, by minimising carbon emissions, combining service adaptability and time-shifting. Finally, to demonstrate the feasibility of our proposal, we introduce CarbonShift, an open-source prototype implementation.

Cloud-Edge application deployment involves placing multiple software components on infrastructural topologies of heterogeneous nodes, ranging from Cloud servers to Internet-of-Things (IoT) edge devices. When multiple versions (or “ flavours ”) of a component are available, application managers must select a flavour for each deployed component, and assign these components to specific nodes, all while considering constraints such as dependencies, quality of service (QoS), budget, operational costs, and carbon emissions. In complex scenarios, finding the optimal deployment is often infeasible for human operators without automated tools to systematically explore the solution space. To address this challenge, we introduce FREEDA, a first constraint optimisation approach for deploying constrained and multi-flavoured applications on Cloud-Edge infrastructure topologies. We demonstrate the practical feasibility of FREEDA through experiments on a variety of realistic Cloud-Edge infrastructural topologies and component architectures. Furthermore, we benchmark FREEDA against Zephyrus, a comparable tool employing the same underlying solving technology. Empirical results show that FREEDA achieves strong scalability across a broad spectrum of realistic configurations and consistently outperforms Zephyrus.

Abstract Architecture recovery tools help software engineers obtain an overview of the structure of their software systems during all phases of the software development life cycle. This is especially important for microservice applications because they consist of multiple interacting microservices, which makes it more challenging to oversee the architecture. Various tools and techniques for architecture recovery (also called architecture reconstruction) have been presented in academic and gray literature sources, but no overview and comparison of their accuracy exists. This paper presents the results of a multivocal literature review with the goal of identifying architecture recovery tools for microservice applications and a comparison of the identified tools’ architectural recovery accuracy. We focused on static tools since they can be integrated into fast-paced CI/CD pipelines. 13 such tools were identified from the literature and nine of them could be executed and compared on their capability of detecting different system characteristics. The best-performing tool exhibited an overall F1-score of 0.86. Additionally, the possibility of combining multiple tools to increase the recovery correctness was investigated, yielding a combination of four individual tools that achieves an F1-score of 0.91.

ABSTRACT Context Identifying the possible root causes of observed failures is crucial in microservice applications, as much as explaining how such possible root failures propagated across the microservices forming an application. This can indeed help pick countermeasures avoiding observed failures to happen again, e.g., by introducing circuit breakers or bulkheads avoiding the root failures to propagate and cause those observed. Objective This paper aims at enabling to explain observed failures in microservice applications, either searching for all possible cascading failures or focusing only on those starting in a known root cause. Method We propose a log‐based root cause analysis technique, which declaratively determines the cascading failures that possibly caused an observed failure. We also enable exploiting our proposed technique in practice, by introducing a logging methodology to instrument applications to log their failures and service interactions, and by enabling to analyse such logs through yRCA, a prototype implementation of our proposed root cause analysis technique. Results The practical usability of our proposed technique is assessed by means of a case study and controlled experiments. The case study shows the low effort for instrumenting a third‐party application to produce the logs needed by our technique and its effectiveness in explaining injected failures. The controlled experiments further assess our technique's effectiveness and performances in explaining failures obtained with an existing chaos testbed. Conclusion Our proposed technique can help to identify the cascading failures that possibly caused an observed failure in a microservice application. It can be used to determine all possible cascading failures, or to explain how cascading failures propagated from a known root cause (e.g., identified with some other existing root cause analyser).

ABSTRACT Domain The deployment of distributed multi‐component cloud applications typically requires a combination of multiple heterogeneous deployment technologies. A different combination of deployment technologies should be chosen due to varying deployment qualities, such as the functional suitability and reliability of the deployment technologies for the deployment of the components. A suboptimal selection of deployment technologies makes the deployment error‐prone. Problem Selecting and maintaining the combination of deployment technologies requires modeling effort and expertise. Contributions We present a method that automatically selects deployment technologies based on a knowledge base of deployment scenarios and corresponding deployment qualities of deployment technologies. Evaluation We show the practical applicability and the usefulness of our method. For the practical applicability, we conduct two case studies based on an open‐source reference architecture application and a real‐world industry application using a prototypical implementation of our method. For the usefulness, we conduct a user study in which participants assign deployment technologies with and without our method. Conclusions Our method is a useful contribution that reduces the modeling effort and the required expertise when maintaining the combination of deployment technologies. Further, our method enhances the deployment quality.

Modern software systems evolve rapidly, especially when boosted by continuous integration and delivery. While many tools exist to help manage the maintainability of monolithic systems, gaps remain in assessing changes in decentralized systems, such as those based on microservices. Microservices fuel cloud-native systems, the mainstream direction for most enterprise solutions, which drives motivation for a broader understanding of how changes propagate through such systems. This position paper elaborates on the role of dependencies when dealing with evolution challenges in microservices aiming to support maintainability. It highlights the importance of dependency management in the context of maintainability deterioration. Our proposed perspective refines the approach to maintainability assurance by focusing on the systematic management of dependencies as a more direct method for addressing and understanding change propagation pathways, compared to traditional methods that often only a ddress symptoms like anti-patterns, smells, metrics, or high-level concepts.

Microservice Architecture (MSA) is a popular approach to designing, implementing, and deploying complex software systems. However, MSA introduces inherent challenges associated with distributed systems—one of them is the detection and mitigation of security smells. This paper draws on recent works that identified and categorized security smells in MSAs to propose a novel end-to-end approach for resolving security smells in existing MSAs. To this end, the presented approach extends a modeling ecosystem for MSAs with (i) reconstruction capabilities that automatically map MSA source code to viewpoint-specific architecture models; (ii) validations that detect security smells from reconstructed models; and (iii) model refactorings that support the interactive resolution of security smells and solutions’ reflection back to source code. Our approach allows for (i) uncovering security smells, which originate from the combination of different places in source code with possibly heterogeneous purposes, technologies, and software languages; as well as (ii) clustering, reifying, and fixing smells using a level of abstraction that is directed towards MSA stakeholders. The applicability and effectiveness of our approach are evaluated utilizing a standard case study from MSA research.

Securing microservice applications is crucial. Security smells denote symptoms of bad –often unintentional– design decisions, which may result in violating security properties, and that can be resolved via refactoring. Stakeholders take into account the services’ business value, problem criticality, and available resources to decide which smells to resolve or leave alone, but making such decisions is inherently complex for microservice applications with many services, possibly affected by multiple security smell instances. Borrowing from hospital emergency room triage practices, which assign an urgency code to incoming patients, this paper introduces the notion of urgency for microservice security smell instances, and proposes the TriSS method to triage them. TriSS enables assigning to each security smell instance with an urgency code based on combining the services’ business relevance and the smells’ impacts on security and other quality attributes, e.g., performance and maintainability. The practical applicability of TriSS is illustrated with a use case based on a third-party microservice application, and its usefulness is evaluated with a controlled experiment involving 26 practitioners. The experiment’s results suggest that TriSS eases the triage process and yields urgency codes on which practitioners are more confident.

Microservices gained momentum in enterprise IT, as they enable building cloud-native applications. At the same time, they come with new security challenges, including security smells, viz., symptoms of bad (though often unintentional) design decisions that might affect application security. This study aims to explore the impacts of microservice security smells- and of the refactorings known to mitigate their effects-beyond security. In particular, we systematically elicit possible impacts of smells and refactorings on applications' maintainability, performance efficiency, and adherence to microservices' key design principles. We then validate the elicited impacts by means of an online survey targeting experienced practitioners and researchers. Our main contributions include 35 validated impacts, and a discussion of the survey results geared towards analyzing the (mis)alignment between practitioners and researchers.

Microservices are getting commonplace, as their design principles enable obtaining cloud-native applications. Ensuring that applications adheres to microservices’ design principles is hence crucial, and this includes resolving architectural smells possibly denoting violations of such principles. To this end, in this paper we propose a semi-automated methodology for resolving architectural smells in microservices applications deployed with Kubernetes. Our methodology indeed automatically detects architectural smells by analyzing the Kubernetes manifest files specifying an application’s deployment, and it can also generate the refactoring templates for resolving such smells. We also introduce KubeFreshener, an open-source prototype of our methodology, which we use to assess it in practice based on a controlled experiment and a case study.

Designing, implementing, and operating microservices is known to be complex and costly, mainly due to the multitude of heterogeneous software services forming a microservice-based application. Such tasks can be simpler if a specification of the microservice-based architecture (MSA) of an application is available. At the same time, due to the number of services and service interactions in a MSA, manually generating a specification of such MSA is complex and costly. For this reason, in this paper we present a novel technique for automatically mining the specification of a MSA from its Kubernetes deployment. The obtained MSA specification is in mu TOSCA, a microservice-oriented profile of the human- and machine-readable OASIS standard TOSCA. We also present a prototype implementation of our technique, which we use to assess it by means of case studies based on third-party applications.

Abstract The management of modern enterprise applications is automated by coordinating the deployment, configuration, enactment, and termination of their components. Choosing among different candidate implementations for a specified application component requires such implementations to conform to the specified management behaviour. This holds especially if we wish to ensure that the overall application management can continue as planned, or that no additional (potentially undesired) management activity gets enabled. To this end, we introduce a formal framework for testing “management conformance”, i.e., to test whether a candidate implementation can be managed according to the management protocol specifying the allowed management for a component. We also illustrate how our framework enables to run four different conformance tests, each providing a different trade-off between implementation freedom and guarantees on the overall application management. We formally prove that testing management conformance with constraints reducing implementation freedom results in preserving all already allowed management activities when implementing a specification by choosing a conforming implementation and that no additional (potentially undesired) management activity gets enabled. Finally, we assess our framework by means of a prototype implementation and its use in an experimental evaluation.

Abstract Function‐as‐a‐Service (FaaS) is a cloud service model enabling to implement serverless applications for a variety of use cases. These range from scheduled calls of single functions to complex function orchestrations executed using orchestration services such as AWS step functions. However, since the available function orchestration technologies vary in functionalities, supported modeling languages, and APIs, modeling such function orchestrations and their deployment require significant technology‐specific expertise. Moreover, the resulting models are typically not portable due to provider‐ and technology‐specific details, and major efforts are required when exchanging an orchestrator or provider due to such lock‐ins. To tackle this issue, we introduce a vendor‐ and technology‐agnostic method for the modeling and deployment of serverless function orchestrations, which relies on the business process model and notation (BPMN) and topology and orchestration specification for cloud applications (TOSCA) standards for modeling function orchestrations and their deployment, respectively. We also present a toolchain for modeling serverless function orchestrations in BPMN, generating proprietary models supported by different function orchestration technologies from BPMN models, specifying their actual deployment in TOSCA, and then enacting such deployment. Finally, we illustrate a case study applying our method and toolchain in practice.

Modern enterprise applications integrate multiple interdependent software components, whose management must be suitably coordinated. This must be done by taking into account all inter-component dependencies, the faults potentially affecting them, and the fact that each component can be horizontally scaled, i.e., that multiple instances of each component can be spawned or destroyed, depending on application needs. In this article, we introduce a novel solution for suitably modelling and analysing the replica- and fault-aware management of multi-component applications, based on topology graphs and management protocols. More precisely, we first introduce a compositional model of the management behaviour of the (possibly multiple) instances of the components forming an application, faults included. We then show how this model enables automating various useful analyses, from checking the validity of management plans to automatically determining management plans allowing the instance of an application to reach and maintain a desired target configuration.

Various deployment technologies have been released to support automating the deployment of distributed applications. Although many of these technologies provide general-purpose functionalities to deploy applications as well as infrastructure components, different technologies provide specific capabilities making them suited for different environments and application types. As a result, the deployment of complex distributed applications often requires to combine several deployment technologies expressed by different deployment models. Thus, multiple deployment models are processed by different technologies and must be either orchestrated manually or the automated orchestration must be developed individually. To address these challenges, we present an approach (i) to annotate parts of a holistic deployment model that should be deployed with different deployment technologies, (ii) to automatically transform an annotated model to multiple technology-specific models for different technolo gies, and (iii) to automatically coordinate the deployment execution with different technologies by employing a centralized orchestrator component. To prove the practical feasibility of the approach, we describe a case study based on a third-party application.

The diversity of available cloud service models yields multiple hosting variants for application components. Moreover, the overall trend of reducing control over the infrastructure and scaling configuration makes it non-trivial to decide which hosting variant suits more a certain software component. In this work, we introduce a spectrum of component hosting patterns that covers various combinations of management responsibilities related to (i) the deployment stack required by a given component as well as (ii) required infrastructure resources and component’s scaling rules. We validate the presented patterns by identifying and showing at least three real world occurrences of each pattern following the well-known Rule of Three.

Function-as-a-Service (FaaS) is a cloud service model enabling developers to offload event-driven executable snippets of code. The execution and management of such functions becomes a FaaS provider’s responsibility, therein included their on-demand provisioning and automatic scaling. Key enablers for this cloud service model are FaaS platforms, e.g., AWS Lambda, Microsoft Azure Functions, or OpenFaaS. At the same time, the choice of the most appropriate FaaS platform for deploying and running a serverless application is not trivial, as various organizational and technical aspects have to be taken into account. In this work, we present (i) a FaaS platform classification framework derived using a multivocal review and (ii) a technology review of the ten most prominent FaaS platforms, based on the proposed classification framework. We also present a FaaS platform selection support system, called FaaStener, which can help researchers and practitioners to choose the FaaS platform most suited for their requirements.

Summary Exploiting microservices to architect enterprise applications is becoming commonplace. This makes it crucial to provide some support for designing and analyzing microservice‐based applications, for example, for understanding whether a microservice‐based application adheres to the main design principles of microservices and for choosing how to refactor it when this is not the case. To provide such support, in this article we present the TOSCA toolchain. More precisely, we first introduce the TOSCA model to represent the architecture of microservice‐based applications with the OASIS standard TOSCA. We then describe a technique to automatically mine the architecture of a microservice‐based application and represent it with TOSCA, given the Kubernetes deployment of the application. We also present a methodology to analyze the TOSCA representation of a microservice‐based architecture to systematically identify the architectural smells potentially affecting the corresponding application and to resolve them. Finally, we present two prototype tools, Miner and Freshener , implementing our mining solution and the support for identifying and resolving architectural smells in microservice‐based applications, respectively. We then assess —by discussing some case studies— how effectively Miner , Freshener , and the TOSCA toolchain can support researchers and practitioners working with microservices.

\n The adoption of cloud computing combined with DevOps enables\n companies to react to new market requirements more rapidly and\n fosters the use of automation technologies. This influences the way\n software solutions are built, which is why the concept of\n cloud-native applications has emerged over the last few years to\n build highly scalable applications, and to automatically deploy and\n run them in modern cloud environments. However, there is currently\n no reference work clearly stating the features that a deployment\n technology must offer to support the deployment of arbitrary\n cloud-native applications. In this paper, we derive three essential\n features for deployment technologies based on the current\n cloud-native research and characteristics discussed therein. The\n presented features can be used to compare and categorize existing\n deployment technologies, and they are intended to constitute a first\n step towards a comprehensive framework to assess deployment\n technologies.\n

\n The automation of application deployment is critical because\n manually deploying applications is time-consuming, tedious, and\n error-prone. Several deployment automation technologies have been\n developed in recent years employing tool-specific deployment\n modeling languages. At the same time, the OASIS standard Topology\n Orchestration Specification for Cloud Applications (TOSCA) emerged\n as a means for describing cloud applications, i. e., their\n components and relationships, in a vendor-agnostic fashion. Despite\n TOSCA is widely used in research, it is not supported by the\n production-ready deployment automation technologies daily used by\n practitioners working with cloud-native applications, hence\n resulting in a gap between the state-of-the-art in research and\n state-of-practice in the industry. To help bridging this gap, we\n leverage the recently introduced Essential Deployment Metamodel\n (EDMM) and identify TOSCA Light, an EDMM-compliant subset of TOSCA,\n to enact the transformation from TOSCA to the vast majority of\n deployment automation technology-specific models used by todayâs\n software industry. Further, we present an end-to-end TOSCA Light\n modeling and transformation workflow and show a prototypical\n implementation to validate our approach.\n

Microservice-based architectures (MSAs) gained momentum in industrial and research communities since finer-grained and more independent components foster reuse and reduce time to market. However, to come from the design of MSAs to running applications, substantial knowledge and technology-specific expertise in the deployment and integration of microservices is needed. In this paper, we propose a model-driven and pattern-based approach for composing microservices, which facilitates the transition from architectural models to running deployments. Using a unified modelling for MSAs, including both their integration based on Enterprise Integration Patterns (EIPs) and deployment aspects, our approach enables automatically generating the artefacts for deploying microservice compositions. This helps abstracting away the underlying infrastructure including container orchestration platforms and middleware layer for service integration. To validate the feasibility of our approach, we illustrate its prototypical implementation, with Kubernetes used as container orchestration system and OpenFaaS used for managing integration logic, and we present a case study.

Summary Enterprise IT is currently facing the challenge of coordinating the management of complex, multicomponent applications across heterogeneous cloud platforms. Containers and container orchestrators provide a valuable solution to deploy multicomponent applications over cloud platforms, by coupling the lifecycle of each application component to that of its hosting container. We hereby propose a solution for going beyond such a coupling, based on the OASIS standard TOSCA and on Docker. We indeed propose a novel approach for deploying multicomponent applications on top of existing container orchestrators, which enables managing each component independently from the container used to run it. We also present prototype tools that implement our approach, and we show how we effectively exploited them to carry out a concrete case study.

The fault handling and recovery from runtime failures of cloud applications should be done by taking into account the inter-dependencies occurring among their components, and by dealing with the diverse and heterogeneous cloud offerings used to host them. The latter is even harder in trans-cloud scenarios, i.e., when application components are possibly deployed on different platforms and at different service levels (IaaS or PaaS). In this paper, we propose a methodology to support the automated management and recovery of (un) foreseen failures in a trans-cloud application, which takes into account all interdependencies occurring among its components. We then present a prototype implementation of our proposal, consisting of an orchestrator that exploits a management framework for trans-cloud application deployments, together with management protocols for the automated planning of the fault-aware administration of applications.

Abstract Estimating the cost of a multi-component application (e.g., its resource or energy consumption) is fundamental in nowadays enterprise IT, especially if we consider that current pricing models are mainly pay per-use. While this is still manageable on small applications, it is really hard to manually estimate the cost of large-scale enterprise applications involving hundreds of interdependent application components. In this article, we formalise the problem of estimating costs of multi-component applications, by representing the structure of an application as a typed directed graph, and by allowing to associate different types of costs with different application components. We show that costs can be fully customised, and that associating different costs with the same application leads to different cost estimation problems defined on that application.We then present an approach for solving cost estimation problems on multi-component applications, which is based on terminating and confluent graph transformations. We also present a prototype implemenation of our approach, which we use to run a case study based on a third-party application.

Containers as a lightweight technology to virtualise applications have recently been successful, particularly to manage applications in the cloud. Often, the management of clusters of containers becomes essential and the orchestration of the construction and deployment becomes a central problem. This emerging topic has been taken up by researchers, but there is currently no secondary study to consolidate this research. We aim to identify, taxonomically classify and systematically compare the existing research body on containers and their orchestration and specifically the application of this technology in the cloud. We have conducted a systematic mapping study of 46 selected studies. We classified and compared the selected studies based on a characterisation framework. This results in a discussion of agreed and emerging concerns in the container orchestration space, positioning it within the cloud context, but also moving it closer to current concerns in cloud platforms, microservices and continuous development.

Summary We introduce DockerAnalyser, a microservice‐based tool that permits building customised analysers of Docker images. The architecture of DockerAnalyser is designed to crawl Docker images from a remote Docker registry, to analyse each image by running an analysis function, and to store the results into a local database. Users can build their own image analysers by instantiating DockerAnalyser with a custom analysis function and by configuring the architecture. More precisely, the steps needed to obtain new analysers are (1) replacing the analysis function used to analyse crawled Docker images, (2) setting the policy for crawling Docker images, and (3) setting the scalability options for obtaining a scalable architecture. In this paper, we also present 2 different use cases, ie, 2 different analysers of Docker images created by instantiating DockerAnalyser with 2 different analysis functions and configuration options. The 2 use cases show that DockerAnalyser decreases the effort required to obtain new analysers versus building them from scratch.

Summary How to flexibly manage complex applications across heterogeneous cloud platforms is one of the main concerns in today's IT enterprise. The OASIS standard TOSCA (Topology and Orchestration Specification for Cloud Applications) and the Docker ecosystem are two emerging solutions trying to address this problem from different perspectives. In this paper, we propose a solution that tries to synergically combine the pros of both TOSCA and of Docker. More precisely, we propose a TOSCA‐based representation for specifying the software components and the Docker containers forming an application. We also present TosKer, an engine for orchestrating the management of multicomponent applications based on the proposed TOSCA representation and on Docker. Finally, we illustrate how TosKer was fruitfully exploited in a concrete case study based on a third‐party application.

Docker containers run from Docker images, which can be distributed through so-called Docker registries. The currently available support for searching images in registries is however limited. Available registries (e.g., Docker Hub) only permit searching images "by name", i.e. by specifying a term occurring in the image name, in the image description or in the name of the user that created such image. In this paper we try to enhance the support for discovering Docker images by introducing DockerFinder, a microservice-based prototype that permits searching for images based on multiple attributes, e.g., image name, image size, or supported software distributions. DockerFinder crawls images from a remote Docker registry, it automatically analyses such images to produce multi-attribute descriptions to be stored in a local repository, and it permits searching for images by querying the local repository.

OASIS TOSCA aims at solving the problem of managing complex applications across heterogeneous clouds by providing a standard, vendor-agnostic language to describe them. TOSCA permits defining a cloud application as an orchestration of typed components, which can be instantiated by matching other TOSCA applications. In this paper we first present two types of behaviour-aware matching of applications, based on a notion of simulation. We then relax this notion by permitting to match an operation with a sequence of available operations, and present a coinductive procedure to compute such relaxed simulation.

The adaptive management of complex applications deployed across multiple heterogeneous PaaS platforms is one of the problems that have emerged with the cloud revolution. The ongoing EU research project SeaClouds aims at providing seamless adaptive multi-cloud management of complex applications by supporting the distribution, monitoring and migration of application modules over multiple heterogeneous PaaS platforms. In this paper we present context, motivations and objectives of SeaClouds, its relation with other cloud initiatives, and its initial architecture.