Abstract

AbstractAs a recently predominant architecture style, MicroService Architecture (MSA) is likely to suffer the issues of poor maintainability due to inappropriate microservice boundaries. Architectural Smell (AS), as a metaphor for potential architectural issues that may have negative impacts on software maintenance, can be used to pinpoint refactoring opportunity for evolving microservice boundary. However, existing studies mostly focus on AS detection with little further investigation on the possible impacts, causes, and solutions of AS, which does little help in addressing the bad smells in architecture. Our goal in this study is to bridge this gap by investigating the possible impacts, causes, and solutions of AS in MSA‐based systems. An industrial case study is carried out to collect repository data and practitioners' views on six typical ASes in a real MSA‐based telecommunication system. Statistical Analysis and Coding techniques are used in the analyses of quantitative and qualitative data respectively. The results show that AS influences the modularity, modifiability, analyzability, and testability of the MSA‐based system, which further induce extra cross‐team communication, change‐ and fault‐prone microservices. To explore the causes for AS, a five‐aspect conceptual classification with technology, project, organization, business, and professional is proposed, in which the business and organization aspects take the major roles. Both technical and non‐technical solutions are distilled to deal with ASes despite potential constraints. These results and their comparison to current literature are discussed, which provide practical implications in coping with AS in microservices.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call