Reducing Technical Debt With Microservices

on Wednesday, 04 February 2015. Posted in News

Reducing Technical Debt With Microservices

Reducing Technical Debt With Microservices

Yet time is scarce when we're building software faster than ever, propelled by the biggest tech boom since the turn of the century. Who can keep up with enormous demands to crank out legions of Web, mobile, big data, and streaming analytics apps? Quick-and-dirty code and expedient design decisions pile up over time to produce what's known as technical debt. I wouldn't be surprised to learn we're now in the process of accumulating technical debt at historic rates.

[ See what best hardware, software, development tools, and cloud services came out on top in the InfoWorld 2015 Technology of the Year Awards. | Cut to the key news in technology trends and IT breakthroughs with the InfoWorld Daily newsletter, our summary of the top tech happenings. ]


Ultimately, technical debt needs to be paid down -- that is, bad code needs to be refactored, questionable design decisions need to be revisited, and so on -- or you risk the equivalent of a default, when stuff starts breaking all over the place. For a spectacular example, look no further than the Knight Capital Group disaster of 2012, where a software update caused "dead code" to come back to life and lost the trading firm $440 million in 30 minutes.

Microservices architecture potentially offers an easier way to pay down technical debt. Refactoring a big monolithic application can be the equivalent of a balloon payment. But if you break down application functionality into API-accessible microservices, each with a single purpose, you can pay your technical debt incrementally by refactoring services one by one.

Speaking about one of his first microservices projects, legendary agile programming advocate Fred George put it this way:

These little services became almost disposable entities. We didn't really care about keeping them around for long periods of time. If it was useless we threw it away and wrote it again.

Sounds like a nice easy payment plan for technical debt, but it comes with a couple of caveats.

The first is the difficulty of testing microservices-based applications -- a point Martin Fowler and James Lewis made in their classic explanation of microservices. (Their colleague Toby Clemson addressed many of the complexities in a presentation a couple of months ago.) A big chunk of technical debt stems from cutting short test cycles to meet deadlines, and if tests become more complex, the temptation to skip them increases.

Another problem is that it's not always clear what constitutes a microservice. This is new territory for many developers. It's perfectly possible to screw up and do microservices architecture badly -- and bad architecture is the hardest technical debt to pay.