I still like microservices

In recent years, the “microservices” approach to service-oriented architectures has faced significant backlash, some of it deservedly so. Tales of Uber’s nightmare of jumbled tech stacks notwithstanding, I believe there is still value in this approach, especially since Kubernetes persistently remains a thing in DevOps.

I think a big strength of the microservice approach has more to do with developer quality-of-life than anything related to site reliability or CI/CD. I know this is well-trodden ground, but recent experience has reinforced some basic truths that companies still manage to screw up in hilarious fashion.

Trying to rewrite your entire platform in one fell swoop is the wrong approach. It’s the classic rewrite-vs.-refactor debate when it comes to paying down tech debt. The better solution is to systematically rewrite bite-sized portions and carefully replace aging legacy code in as small chunks as you can get away with. Inability to take the better approach is almost always a failure of management, not of developers, by the way.

I encourage the interested reader to check out the sad, cautionary tale of Sonos’ new app roll-out. (For extra credit, check out what happened with the launch of EA’s Battlefield 2042.) Sonos’ platform was saddled with over 20 years of unpaid tech debt. That by itself communicates volumes about the quality of Sonos management. It’s a common trope, though, and certainly not isolated to Sonos.

The disease is one of managers that, in one form or another, are defined by what products and new features they can roll out. After all, if there are no new features, how will we know managers are doing anything at all? Google has become a running joke of failed product launches because, as rumor has it, managers are allegedly compensated based on launching products, rather than making sure they remain usable for the poor consumers that end up relying on them.

I pity the poor souls (many of them business-owners) that had the rug pulled when they lost critical functionality because of the Sonos rollout. Could this sadness have been avoided? Yes, but it takes managers willing to push pause on feature rollouts and create windows where tech debt can be addressed by the dev teams involved in building and maintaining said debt.

In my estimation, if a platform is built on microservices, you already possess a map to all the regions of your codebase where tech debt can be addressed. And not only do you have the map, but if your dev teams made sure to keep services loosely coupled and minimized leaky abstractions, then you can easily address specific services in a systematic approach that avoids problems endemic to “The One Big Rewrite”. Features don’t get dropped on the floor, but are updated and replaced in manageable chunks.

I have personally seen several companies go down the path of rewriting a content pipeline or a supply chain management package, trying to solve everything for everyone. These projects are always monolithic in approach, go overbudget for time and money, and inevitably miss important basic functions or pain points that users actually need solutions for.

This seems so obvious. I feel like a kindergarten teacher trying to explain, “by the way, isn’t it great that 2+2=4?” And yet every year another major corporation is crippled by managers who don’t know how to properly manage tech debt. Profits evaporate, margins disappear, and ultimately jobs are lost.

Well, what if your codebase isn’t so cleanly delineated? What if spaghetti is everywhere and there is no easy road to refactoring? You can only eat an elephant sandwich one bite at a time. If you notice the symptoms of too much tech debt, like increasing time needed to build a new feature or major fires started whenever a new version is released to production, you’re already drowning. But it’s never too late to take a step back and sit your dev teams down and start building and prioritizing tech debt tasks. I guarantee every dev that has spent any amount of time with a particular set of code will absolutely have a laundry list of pain points that they would love to solve.

If the bleeding is especially severe, meaning everything is currently on fire because of too many shaky rollouts, enforce a code freeze immediately. Identify and triage all of the breaking issues (i.e., what’s generating Fatal/Error logs in production) and get them fixed. Then, once production is stable, try to attack the debt. A good approach is to have your devs meet maybe once a month and brainstorm what tech debt needs to be addressed in their sphere of influence. Write down everything and prioritize items into “Must Do”, “Should Do”, “Would Be Nice To Do”, and “Haha Yeah Sure”. Must Do items are things that have to be addressed before any more feature work should even be considered. Then, start including those items in your sprints and Kanban boards.