Abstract
Many companies migrate to microservices because they help deliver value to customers quickly and continuously. However, like any architectural style, microservices are prone to architectural technical debt (ATD), which can be costly if the debts are not timely identified, avoided, or removed. During the early stages of migration, microservice-specific ATDs (MS-ATDs) may accumulate. For example, practitioners may decide to continue using poorly defined APIs in microservices while attempting to maintain compatibility with old functionalities. The riskiest MS-ATDs must be prioritized. Nevertheless, there is limited research regarding the prioritization of MS-ATDs in companies migrating to microservices. This study aims to identify, during migration, which MS-ATDs occur, are the most severe, and are the most challenging to solve. In addition, we propose a way to prioritize these debts. We conducted a multiple exploratory case study of three large companies that were early in the migration process to microservices. We interviewed 47 practitioners with several roles to identify the debts in their contexts. We report the MS-ATDs detected during migration, the MS-ATDs that practitioners estimate to occur in the future, and the MS-ATDs that practitioners report as difficult to solve. We discuss the results in the context of the companies involved in this study. In addition, we used a risk assessment approach to propose a way for prioritizing MS-ATDs. Practitioners from other organizations and researchers may use this approach to provide rankings to help identify and prioritize which MS-ATDs should be avoided or solved in their contexts.
Highlights
When companies migrate their software towards a microservice architecture, the software is split into a small set of independent services
De Toledo et al.: Accumulation and prioritization of architectural technical debt (ATD) in three companies migrating to microservices
De Toledo et al.: Accumulation and prioritization of ATD in three companies migrating to microservices used the same reasoning as before to calculate Equations 4 and 5
Summary
When companies migrate their software towards a microservice architecture, the software is split into a small set of independent services. We consider ATDs only in the context of microservices applications and name them MS-ATDs. One of the reasons for companies to migrate to microservices is repaying known ATDs from their previous architectures while, at the same time, obtain the benefits of this new architectural style. A few other studies have investigated TD and related concepts in this new architectural style [2], [7], [8] None of these studies have covered how ATD has accumulated during migration from a prior architecture to microservices. Answering RQ4 highlights which MS-ATDs practitioners consider risky (important to them) and, should be prioritized for removal or mitigation. RQ5 investigates how companies can prioritize the removal or mitigation of MS-ATDs identified and discussed in the previous questions (see Figure 2).
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
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 callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
