among those debts. manage and avoid architectural debts. Background: Using a microservices architecture is a popular strategy for software organizations to deliver value to their customers fast and continuously. However, scientific knowledge on how to manage architectural debt in microservices is scarce.
The microservices architectural style is becoming increasingly popular in the industry.
Microservices are small and independent components, each with a single responsibility and developed
for scalability [
We conducted a multiple-case study in seven international Europe-based companies to investigate ATD in some of their microservices projects through the following research questions: • RQ1: What are the most critical ATD issues in microservices? • RQ2: What are the negative impacts of such ATD issues? • RQ3: What are possible solutions to repay or avoid such ATD issues?
We aimed to support practitioners’ decision-making in projects involving microservices. This
article is a continuation of a previous single case study [
The most accepted definition of the microservices architecture was proposed by Lewis and Fowler [5]: an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API [5]. Microservices may also be considered a way of implementing Service Oriented Architecture (SOA) [6]. They have both advantages, such as being easier to scale and having shorter cycles for testing, build and release, and disadvantages, such as the additional operational complexity [7].
Architectural Technical Debt (ATD) is a type of technical debt (TD) related to software architecture. ATD is considered the most challenging type of TD to be unveiled and managed, mostly because of the lack of research and tool support [8]. As any TD, the term involves three main concepts: the debt, which is the sub-optimal solution with short-term benefits, but that generate future additional costs; the interest, which is the extra cost generated by the debt; and the principal, that is the cost of developing a solution that avoids the debt or the cost of refactoring such debt [9]. Accumulating the debt might be useful in some circumstances [10]. Understanding the debt and the costs involved might help in the decision-making process. • Debt: The debt is the sub-optimal solution with short-term benefits, but that generates future additional costs (the interest). A solution that was suitable before might also become a debt later. • Interest: The interest is the extra cost that must be paid because of a debt or the amount that will be saved if there is no such debt. • Principal: The principal is the cost of developing a solution that avoids the debt or the cost of refactoring such debt.
Accumulating the debt might be useful in some circumstances [10]. Understanding the debt and the costs involved might help in the decision-making process.
B Cloud This study identified the most common and critical ATD issues in projects using microservices. We also identified the interests and principals related to those ATDs. We conducted an exploratory multiple-case study in seven diferent software products, each one developed in a distinct company in a diferent context. Table 1 shows a summary of the studied companies and project contexts. We identify the companies by letters from A to G.
We prepared an interview guide and performed 25 interviews with 22 employees in diferent roles. New aspects emerged as we progressed with the interviews. Therefore, we updated the interview guide and updated the missing details from previous interviews during complementary interviews with the previous companies.
We found 16 ATDs and discussed their interest and principal. Table 2 presents the ATDs found and the respective companies. We also discussed the interests and principals of each of those ATDs. Distinct companies have diferent ATDs. Not all companies have the solution for the issues found. Thus, the experiences from other companies might be helpful for them. Some ATDs seem to be more common than others.
Some of the ATD found caused substantial interest. Some were related to cascading breaks, unnecessary complexity, coupling, and dependencies among teams. Our results should help practitioners manage ATD by learning from the experience of other companies. A, E A, E A, B, C, E, F A A, E, F, G A, D, E, F B A, B, C, D, E, F, G B, E
URL: https://ieeexplore.ieee.org/document/8786035/. doi:1 0 . 1 1 0 9 / t e c h d e b t . 2 0 1 9 . 0 0 0 2 6 . [5] J. Lewis, M. Fowler, Microservices: a definition of this new architectural term, 2014. URL: https://www.martinfowler.com/articles/microservices.html. [6] O. Zimmermann, Microservices tenets: Agile approach to service development and deployment, Computer Science - Research and Development 32 (2017) 301–310. URL: http://link.springer.com/10.1007/s00450-016-0337-0. doi:1 0 . 1 0 0 7 / s 0 0 4 5 0 - 0 1 6 - 0 3 3 7 - 0 . [7] M. Fowler, Microservice Trade-Ofs, 2015. URL: https://martinfowler.com/articles/ microservice-trade-offs.html. [8] P. Kruchten, R. L. Nord, I. Ozkaya, Technical debt: From metaphor to theory and practice, IEEE Software 29 (2012) 18–21. URL: https://ieeexplore.ieee.org/document/6336722. doi:1 0 . 1 1 0 9 / M S . 2 0 1 2 . 1 6 7 . [9] P. Avgeriou, P. Kruchten, I. Ozkaya, C. Seaman, Managing Technical Debt in Software Engineering (Dagstuhl Seminar 16162), Dagstuhl Reports 6 (2016) 110–138. URL: http: //drops.dagstuhl.de/opus/volltexte/2016/6693. doi:1 0 . 4 2 3 0 / D a g R e p . 6 . 4 . 1 1 0 . [10] T. Besker, A. Martini, R. Edirisooriya Lokuge, K. Blincoe, J. Bosch, Embracing Technical Debt, from a Startup Company Perspective, in: 2018 IEEE International Conference on Software Maintenance and Evolution (ICSME), IEEE, 2018, pp. 415–425. URL: https: //ieeexplore.ieee.org/document/8530048/. doi:1 0 . 1 1 0 9 / I C S M E . 2 0 1 8 . 0 0 0 5 1 .