The folly of microservices

I’m sure I’m not the first to make some of these observations about the microservices fad, but here’s my perspective nonetheless.

Microservices are definitely all the rage, and proffered as an obvious solution to the dreaded monolith. But I'm not so sure it's all that obvious. As another swing at service-orientation, which is really about composability and modularity, it has the same appeal as previous iterations.

What I find disappointing about microservices is the emphasis on technologies over decomposition techniques. Its more concerned with how to run and deploy services than it is about how to identify the proper boundaries and granularity of services. It tells you how to run a service, without telling you what a service should be or do.

Even when it comes to technologies, it's not a no brainer. More services and more technologies (containers, orchestrators) often means more complexity to manage, and a system that is harder to reason about. That complexity management requires yet more technology. All fun and cool for us technology folks, but not clearly necessary.

Applying the technology solutions of microservices without the proper system decomposition will actually lead to some pretty bad outcomes (distributed monolith). There seem to be two class of problems here:

  • Taking non-modular code and distributing that over the network, is unlikely to improve anything.
  • Avoiding decomposition, by choosing extremely granular services, and distributing those over the network can be even worse.

Microservices are a technique to solve a certain type of problem.  They are not a goal in of themselves (unless you're doing resume-based development or a variant thereof). So it's important to understand what you are trying to solve with them.

My impression is that it is a solution to a problem of large teams, with well-defined responsibilities, that would benefit from the increased encapsulation, independence and deployment technologies. They do not seem like a good solution for a small team with broad responsibilities, or with poorly defined system boundaries and/or team responsibilities.

Sometimes modularity itself is enough, without all the tech, but where's the fun in that? And what's the next hiring manager going to say when I don't have years of microservice experience?


Popular posts from this blog

RIF Notes #42

RIF Notes #4

The greatest trick the AI ever pulled was convincing the world it wasn't THAT intelligent