- The first case study comparing technical debt before and after the migration to microservices
- After the introduction of a new microservice, the Technical debt always increase
- In less than two months from the introduction of a microservice, the Technical Debt tends to grow slower thanin the monolithic system
We conducted a case study analyzing the code TD of the system under development for a time-frame of four years (two years before and for two years after the migration). Then we conducted a focus group to analyze in-deep the postponed activities and to get more insights on the results.
The first immediate result is that TD grows ~90\% slower after the development of microservices. After the initial introduction of each microservice, TD grows for a limited period of time, mainly because of the new development activities. When the code of the microservice stabilizes, TD decreases and starts growing linearly, with a growing trend much lower than the monolithic system.
Unexpectedly, when comparing the distribution of TD types before and after the introduction of microservices, important and statistically significant differences emerge. The proportion of SonarQube rules classified as bugs and security vulnerabilities decreased while code smells (maintainability issues) increased. Since microservices are supposed to ease software maintenance, we expected a reduction of code smells.
Developers confirmed the overall results, perceiving a reduced maintenance complexity.
The overall development effort increased after the introduction of microservices, probably because of the extra effort due to the re-development of the system. However, the manager confirmed that the increased velocity and the increased team freedom compensate for the extra effort required.
Future work includes the investigation of the impact of other types of TD during the migration to microservices. We aim at analyzing the same projects using tools detecting architectural smells. Moreover, we aim at investigating the TD due to temporary architectural decisions.
Our next goal is to understand how long different activities could be postponed before the benefit of postponing an activity is canceled out by the increased effort needed to refactor it. As an example, if an activity has an interest equal to zero (i.e., if the development/refactoring effort does not increase if postponed), it can be postponed until it is needed, whereas if an activity has a monthly interest of 10% (i.e., 10% extra interest per month), it should be refactored as soon as possible before getting too expensive.
A more detailed report can be find in the related publication [1]
Nyyti Saarimäki, Francesco Lomio, Valentina Lenarduzzi, Davide Taibi:
Does Migrate a Monolithic System to Microservices Decreases the Technical Debt? CoRRabs/1902.06282 (2019)