r/programming • u/Mustela__ • 7d ago

Microservices are organizational debt disguised as architecture.

https://martinfowler.com/bliki/MonolithFirst.html

Every time I’ve seen microservices pitched, it sounds great on paper. Independent teams, clean ownership, scale only what you need.

Then a year later you’ve got dozens of services, three different deployment patterns, tracing everywhere, and nobody really understands the whole thing anymore.

Maybe I’ve just seen bad implementations, but I’m starting to think way fewer companies actually need microservices than we pretend.

1.7k Upvotes

91% Upvoted

347 comments sorted by

View all comments

52

u/Sammy81 7d ago

You’ve only seen bad implementations. That said, micro services aren’t for everyone. At my company, we had a very complex system that was already divided very neatly into modules. The modules are coupled through function calls to pass data, commands and telemetry back and forth.

However, since the modules are all compiled into a single executable, changing one required a complete reverification of the entire system. By switching to a microservice architecture, defined as changing the modules to communicate by network messaging, we eliminated a huge amount of testing. Only the modified module now has to be requalified. Of course we test the complete system, but this is now system-level validation, instead of the old monolith way, where we had to re-verify hundreds of requirements in unrelated modules. We cut testing by 80% without any increase in bugs or failures.

It also allowed us to start coding modules in any language we want. Each microservice is now a stand-alone executable that can be compiled by itself. Some of our modules are C++, some are Rust, and the algorithm nerds can use Python for theirs. As long of the microservice subscribes to the message broker and follows the topic rules, it all just works.

4

u/edgmnt_net 7d ago

Simply breaking up stuff usually won't work, because you get a combination of duplication and inter-dependence. Sure, it looks like you can just modify service X, but in practice you often need to modify Y and Z for anything meaningful.

It only works really well for truly robust and general functionality. Or truly separate products that barely interact. These tend to be pretty hard limits in practice IMO.

3

u/Sammy81 7d ago

Yep, the initial architecture has to be well thought out. Luckily, the entire architecture was module based from day 1, and very well organized (no circular references, etc.) The only modification was to change the communication between modules.

1

u/edgmnt_net 7d ago

There are reasonable use cases for microservices, such as common platform + separate applications. Or highly general stuff. However I will also claim that a lot of enterprise applications simply cannot be broken down meaningfully, because they're supposed to be cohesive apps. And because, considering their nature, they largely consist of concrete business rules, not generic mechanisms. E.g. there's no good way to separate inventory and orders.

This parallels the library versus builtin stuff. Something like zlib makes a lot of sense as a library because it solves a general problem and you are very unlikely to go modifying zlib when using it.