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: http://www.infoworld.com/article/2878659/application-development/reducing-technical-debt-with-microservices.html