Does migrating a monolithic system to microservices decrease the technical debt?

Lenarduzzi, Valentina; Lomio, Francesco; Saarimäki, Nyyti; Taibi, Davide

doi:10.1016/j.jss.2020.110710

Cited by 58 publications

(31 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…There are several future directions for the research presented in this paper. First, we will replicate this study non-academic context, with a different cohort and on larger projects, with different static analysis tools [15], and in different projects [13]. Second, we will better investigate the perceived severity of each rule, so as to understand if there is common agreement on the classification, or if it is completely context-dependent.…”

Section: Resultsmentioning

confidence: 99%

How long do Junior Developers take to Remove Technical Debt Items?

Lenarduzzi

Mandić

Katin

et al. 2020

Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

Self Cite

View full text Add to dashboard Cite

Background. Software engineering is one of the engineering fields with the highest inflow of junior engineers. Tools that utilize source code analysis to provide feedback on internal software quality, i.e. Technical Debt (TD), are valuable to junior developers who can learn and improve their coding skills with minimal consultations with senior colleagues. Objective. We aim at understating which SonarQube TD items junior developers prioritize during the refactoring and how long they take to refactor them. Method. We designed a case study with replicated design and we conducted it with 185 junior developers in two countries, that developed 23 projects with different programming languages and architectures. Results. Junior developers focus homogeneously on different types of TD items. Moreover, they can refactor items in a fraction of the estimated time, never spending more than 50% of the time estimated by SonarQube. Conclusion. Junior Developers appreciate the usage of SonarQube and considered as a useful tool. Companies might ask junior developers to quickly clean their code.

show abstract

Section: Resultsmentioning

confidence: 99%

How long do Junior Developers take to Remove Technical Debt Items?

Lenarduzzi

Mandić

Katin

et al. 2020

Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

Self Cite

View full text Add to dashboard Cite

show abstract

“…As long as the public API does not change, internal modifications of one service are more straightforward, easier, and less costly than in the case of a similar change in a traditional model. Microservices are autonomous and communicate via open protocols, hence they can be developed fairly independently and even with different technologies [5], [41]- [43].…”

Section: B Microservice Architecturementioning

confidence: 99%

Monolithic vs. Microservice Architecture: A Performance and Scalability Evaluation

2022

View full text Add to dashboard Cite

Context. Since its proclamation in 2012, microservices-based architecture has gained widespread popularity due to its advantages, such as improved availability, fault tolerance, and horizontal scalability, as well as greater software development agility. Motivation. Yet, refactoring a monolith to microservices by smaller businesses and expecting that the migration will bring benefits similar to those reported by top global companies, such as Netflix, Amazon, eBay, and Uber, might be an illusion. Indeed, for systems that do not have thousands of concurrent users and can be scaled vertically, the benefits of such migration have not been sufficiently investigated, while the existing evidence is inconsistent. Objective. The purpose of this paper is to compare the performance and scalability of monolithic and microservice architectures on a reference web application. Method. The application was implemented in four different versions, covering not only two different architectural styles (monolith vs. microservices) but also two different implementation technologies (Java vs. C# .NET). Next, we conducted a series of controlled experiments in three different deployment environments (local, Azure Spring Cloud, and Azure App Service). Findings. The key lessons learned are as follows: (1) on a single machine, a monolith performs better than its microservice-based counterpart; (2) The Java platform makes better use of powerful machines in case of computation-intensive services when compared to .NET; the technology platform effect is reversed when non-computationally intensive services are run on machines with low computational capacity; (3) vertical scaling is more cost-effective than horizontal scaling in the Azure cloud; (4) scaling out beyond a certain number of instances degrades the application performance; (5) implementation technology (either Java or C# .NET) does not have a noticeable impact on the scalability performance.

show abstract

“…In Cloud-based systems, the impact of migrating from monolith and of postponed activities on TD is still not clear. Only limited number of studies have investigated the impact of postponed activities on TD, especially in the context of microservices [11], [6].…”

Section: Technical Debt For Cloud-native Architecturesmentioning

confidence: 99%

“…Migrating from monolith to Cloud based system should lead as consequence to a significant decrease of the maintenance cost. However, in the long run, TD grows slower after the migration process [6]. One of the possible cause could be the deal with a new system architecture.…”

Section: Technical Debt For Cloud-native Architecturesmentioning

confidence: 99%

“…One of the possible cause could be the deal with a new system architecture. Developers should consider various aspects such as enabling the legacy system to communicate via Enterprise Service Bus with the microservices, dealing with authentication issues as well as with process-related issues such as the introduction of the DevOps culture, including continuous building and delivery [6].…”

Section: Technical Debt For Cloud-native Architecturesmentioning

confidence: 99%

See 1 more Smart Citation

Toward a Technical Debt Conceptualization for Serverless Computing

et al. 2021

Self Cite

View full text Add to dashboard Cite

Serverless computing is an emergent compute paradigm reducing processing and operational units to single event-driven functions for orchestration. With its micro-granular architectural characteristics, serverless computing is bound to produce a currently inconceivable set of architectural issues and challenges in the medium-and long-term. Therefore, it is going to become more and more important to define Technical Debt (TD) items-that is, a way to measure the additional long-run project cost connected to immediately-expedient technical decisions-for serverless computing as well as hybrid compute models (e.g., Serverless + Microservices hybrids). This article illustrates a conceptualization and research roadmap in the direction of defining such TD items starting from a technical overview on serverless computing.

show abstract

Does migrating a monolithic system to microservices decrease the technical debt?

Cited by 58 publications

References 12 publications

How long do Junior Developers take to Remove Technical Debt Items?

How long do Junior Developers take to Remove Technical Debt Items?

Monolithic vs. Microservice Architecture: A Performance and Scalability Evaluation

Toward a Technical Debt Conceptualization for Serverless Computing

Contact Info

Product

Resources

About