Why developer freedom may be worth microservices’ headaches

Microservices may be the shiny new developer toy, but they create all sorts of problems. Here’s why they’re worth it, all the same.

Oh, sure. You’ve heard the reasons all the “10X developers” have switched from monoliths to microservices. Easier to understand and manage! Greater flexibility through independent components! Scale! Etc. On his way toward injecting caution into the rush from monolithic architectures to microservices (“Microservices are, in that essence, a religious belief that we should approach with skepticism”), industry consultant Michael DeHaan pointed out a very powerful reason for microservices that has nothing to do with technical merit: microservices re-introduce humanity into software development.

Let me explain.

Choose your adventure

Actually, let’s have DeHaan explain: “[M]icroservices are mostly present because teams want to make their own choices, dislike code review or overbearing ‘architects’ above them, and to a lesser extent want to use different and newer languages.” In other words, they want to express their creativity with as few constraints as possible.

As mentioned, microservices allow a company to break up an application into independent components. Different teams can use their tools and languages of choice. It’s a bonanza of freedom, as Gartner analyst Raj Bala has said: microservices allow you to “mix and match programming languages and frameworks like never before.”

SEE: Google Workspace vs. Microsoft 365: A side-by-side analysis w/checklist (TechRepublic Premium)

Is this a big deal? Absolutely, noted Sam Ramji, chief strategy officer at Datastax: “Economics is psychology at scale. Even if [Dehaan’s quote above] were the only truth, it would be sufficient to build an industry around.” Why? Because, stressed Madala Software CTO Damien Hocking, “Development is still a human-centric activity.”

Microservices, in short, give developers the opportunity to express themselves using their preferred approaches to programming. That’s a big deal.

Not that this developer freedom to choose comes without costs. As DeHaan explained in detail:

“As we seek to avoid code review, changes in one microservice may require hundreds of different teams to make a corresponding change. Code sharing across languages is also completely lost, as basic functions must be reinvented, sometimes with unfortunately differing business logic! … [Plus m]icroservices reverse … things [like full-stack tracing], and leave us with inefficient communications, less error detection in development, easier ways to introduce errors, a massively worse debugging experience relying on searching further through distributed log analysis tools, systems that crash more often, and require more and more management-software to deploy.”

And yet … the human side.

Maybe DeHaan is correct. Maybe in our rush to microservices “we overcomplicated our IT infrastructures, lost efficiency in our cloud deployments and made debugging an utter hellscape.” Maybe. And maybe cloud conspired to make all of this chaos possible. Maybe.

SEE: Top keyboard shortcuts you need to know (free PDF) (TechRepublic)

But coming back to Ramji’s point, the “chaos” supposedly created by microservices is worth it if it gives developers freedom. We can argue that things should be otherwise, but we’ve spent decades enabling developers to act for themselves and not be acted upon (except by those unintended consequences that DeHaan calls out) through open source, cloud and more. There’s no denying that microservices create plenty of problems on its way to enable developer autonomy, as I’ve cataloged.

But there’s a reason they’re sticking around, despite those problems. Developer freedom is a powerful drug. The best organizations will figure out how to maximize that freedom while imposing just enough structure to minimize some of the problems microservices can introduce.

Disclosure: I work for MongoDB, but the views expressed herein are mine.