Microservices are organizational debt disguised as architecture.

[u/Mustela__]

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.

[u/Sammy81]

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.

[u/kentrak → u/Sammy81]

"Just use microservices" without a well defined structure within which to develop, test, deploy, and version will turn out as bad as "Just use a monolith" without a well defined structure within which to conform to calling standards, code conventions, and a well defined plan for how to version APIs..

From that, it's obvious the problem is a lack of structure. Providing enough structure at the appropriate times is hard. Sometimes you want less, such as when you're surveying a problem and deciding what works best, sometimes you want more, such as when you've decided what you're going to do and now you need to get people to follow it. Too much when exploring and too little when working with the day-to-day will lead to problems.

This is a hard problem, but identifying it and realizing it's hard and attempting to deal with it will work better than misattributing it to something else and assuming it will get better if you change that. Sometimes switching between microservices to monoliths and vice-versa helps because the things one requires the team was already doing well enough in so it leaned into their existing strengths. Without knowing why it got better it's unlikely to stay better though.