Could Microservice be the solution for technical debt

I have mixed feelings about Microservices – it is a not a free lunch, it will be constrained by “Conway's law”, see my blog on “Some laws do not change”, but recently I am starting to embrace it more. I am wondering if it could be the ultimate solution for technical debt. 

I don’t like the term of technical debt, naming it “technical debt” doesn’t bring about the urgency that is necessary to trigger actions, see my blog “We need a better metaphor than technical debt”.

So now technical debt has reached a point that is impossible to payoff – it is killing the little poor donkey:

How can we unload its burden while still making it moving?

The problem of this approach of reducing technical debt is:

• It takes a lot of effort, it might not be easy to secure funding to pay for this effort.

• Even if there is a lot of funding to do refactor, there will huge opportunity cost: while the team is refactoring the system, they won’t be able to work on ideas that will attract users (having a maintainable system is an appealing thing for users, but that is what they rightfully expect, not something they would pay extra money for)

Microservice might be the way to not killing the donkey while moving it as fast as possible. The idea is, new ideas will be implemented as Microservices, while old, bulky stuff will be remained in the old system:

 

The donkey remains to a donkey, but new ideas will be inside some little shiny cars, which can be designed and implemented quickly. 

You will notice that some load on the donkey is removed, because to practice Microservice well, some changes have to be made, not only on the system itself, but also on the organization structure, otherwise, it will be a big mess.