Introduction: Software companies aim to achieve continuous delivery to constantly provide value to their customers. A popular strategy is to use microservices architecture. However, such an architecture is also subject to debt, which obstructs the continuous delivery process and thus negatively affects the software released to the customers. Objectives: The aim of this study is to identify issues, solutions and risks related to Architecture Technical Debt in microservices. Method: We conducted an exploratory case study of a real life project with about 1000 services in a large, international company. Through qualitative analysis of documents and interviews, we investigated Architecture Technical Debt in the communication layer of a system with microservices architecture. Results: Our main contributions are a list of Architecture Technical Debt issues specific for the communication layer in a system with microservices architecture, as well as their associated negative impact (interest), a solution to repay the debt and the its cost (principal). Among the found Architecture Technical Debt issues were the existence of business logic in the communication layer and a high amount of point-to-point connections between services. The studied solution consists of the implementation of different canonical data models specific to different domains, the removal of business logic from the communication layer, and migration from services to use the communication layer correctly. We also contributed with a list of possible risks that may affect the payment of the debt, as lack of funding and inadequate prioritization. Conclusion: We found issues, solutions and risks that are specific for microservices architectures not yet encountered in the current literature. Our results may be useful for practitioners that want to avoid or repay Technical Debt in their microservices architecture.

Background: Software systems must continuously evolve to meet new business requirements. A modular software architecture is key to facilitating the evolution of the system. Many software development organizations also require their software to be deployed on the cloud due to demands on scalability and availability. Microservices is an architectural style that allows the implementation of all these requirements. However, software architecture is prone to sub-optimal solutions, because of several factors such as time constraints, uncertainty, miscommunication, and the growing complexity of software systems. Such factors may lead to architectural technical debt (ATD). There are only a few studies about ATD in the context of microservices (MS-ATDs).Objective: This work aims to understand what MS-ATDs are, including their costs and solutions, and investigate methods to support their quantification, prioritization, and management.Method: The reported studies combined qualitative and quantitative research methods. We started with a multiple case study in seven large software development organizations to identify MS-ATDs, costs, and solutions. We then proceeded with an in-depth multiple case study in four large software development organizations on how a specific MS-ATD, the misuse of shared libraries, affects development agility. Next, we performed another multiple case study in three large software development organizations in the early stages of migration to microservices to understand how MS-ATDs occur during migration and how they can be prioritized. Finally, we conducted a quantitative case study in a large company before and after refactoring some MS-ATDs to understand how the refactoring affected the occurrence of incidents. We used incidents as a proxy of MS-ATD costs.Results: Our results include a catalog of MS-ATDs, their causes, their solutions, a quantification of the debts' interest based on the number of incidents resulting from the debts, and an approach to prioritize MS-ATDs. Examples of MS-ATDs are the lack of communication standards among microservices, the misuse of shared libraries, and an excessive number of small products. We report negative effects of misusing shared libraries on development agility. We also presented suggestions of how software development organizations could deal iii Abstract with this problem. Finally, we proposed a systematic prioritization approach for MS-ATDs based on factors such as the likelihood of their occurrence, the difficulty of their resolution, and their importance for the practitioners.Conclusion: Software development organizations are still learning how to use microservices and pay a high interest due to the lack of experience with this architectural style. Such organizations can use our catalog to identify 16 different MS-ATDs, their costs, and solutions. They can also integrate our lightweight MS-ATD prioritization approach into their agile development processes. Researchers can find our results valuable in understanding MS-ATDs and contributing to reducing the...