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.

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.

The Open Innovation paradigm has spread widely since 2003, and led to the emergence of Open Innovation Platforms as software systems aiming at supporting and facilitating open innovation initiatives and projects. This software domain has matured up to a point where many functional concepts became notably common and used in these platforms. When implementing open innovation platforms, related people often struggle when defining expected functional characteristics due to the general application of the paradigm, making necessary the existence of a model that provide a set of potential functional features expected in the creation and development of this type of platform. Reference models provides a domain-specific set of clearly defined entities aiming at encouraging better communication in the domain. We propose in this paper a reference model for capturing and defining the functional features that could be implemented in outside-in oriented open innovation platforms. For building this reference model, we reviewed some of the already published reports of open innovation platforms implementations in order determine and define the potential functional features expected in this kind of platforms. We believe this knowledge base could ease software development and deployment decisions, especially at early stages where open innovation platforms adopters face development in a domain that as of this writing is still new to many people.