Microservices Architecture & Reducing Technical Debt


Paying off technical debt, according to this post, can be made easier with microservices architecture. When building a code base, eventually, trade-offs between quality and delivering on time will arise. The benefit of trade-offs in software is that the option to later go back and fix these shortcuts is available. Quick and dirty shortcuts and expedient design decisions build up over time and create technical debt, which needs to be paid pack before it reaches unmanageable levels. This entails refactoring bad code and reviewing questionable design decisions before defaulting on the debt created. Once the debt has been defaulted on, things start breaking all over the code base and makes working almost impossible.

Microservices architecture could offer an easier way to pay back technical debt in a software environment where delivery speed is increasingly more important. By breaking down app functionality into API-accessible microservices, each service with its own purpose, paying technical debt can be done incrementally service by service.

There are a few reasons why microservice architecture may prove to be a little more difficult to enact than it seems; first is the difficulty in testing microservices-based-apps and second is that it is not always clear what a microservice necessarily entails. Lack of testing is often a source of technical debt because when pressed to meet stringent deadlines the testing cycle is often cut short – therefore, if testing becomes more complex, the more likely skipping them becomes. Also, in creating microservices architecture it is possible mess up and end up creating bad architecture, and bad architecture is the hardest technical debt to pay off.

Although there are complications to using microservices architecture it is likely to continue its growth in popularity. The ease in paying technical debt with this architecture is not the only reason for this, but also because it allows tapping into an existing service rather than coding from scratch. It also gives business the ability to create applications that are adaptable to change over time. However, microservices do not magically resolve problems of technical debt instantaneously; recording where and how much debt exists in the code base is necessary for any organization to keep its debt in check.

The environment in which development is occurring has just as much to do with successfully managing debt as what architecture or techniques are used to address it. If impossible deadlines are the norm, than technical debt often is passed down the line and results in high developer turn over within an organization; there is not much to be done in such a case and debt default is likely.

To read the full post go to: 

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item