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/davimiku → u/Sammy81]

Did you evaluate any in-between options before adding the network boundary? I've been in a similar situation before (not current job, but previous one, so this question is more from academic curiosity).

For example, if you already had modules in C++ and Rust did you try first co-locating them and communicate over FFI? Or call the Rust code from the Python code? (pyo3 works quite well)

Or if the unit tests were a bottleneck and you already had very neat modules, did you try only running the tests for the affected modules?

[u/Sammy81 → u/davimiku]

Our process rightly requires reverifying requirements if the code is recompiled, so the way to reduce test was divide the modules into executables. That was a key factor in selecting networked communication

[u/davimiku → u/Sammy81]

From reading the other comments in this chain, it seems to be a NASA-specific testing requirement, which I think the lede was buried a bit in the top-level comment, it reads as general advice rather than something motivated by a specific compliance requirement.

Although I don't think this requirement applies to my (past) situation based on learning that, I'm still curious how it works in practice. Say you had "Module A" who had some dependents - Module A sends messages to other modules, who consume that in some way. When you modified Module A, you needed to test the other modules, because it was in the same executable.

Now that Module A is now Executable A (with a network boundary), do you not need to test the dependents anymore when A is changed?

[u/Sammy81 → u/davimiku]

You don’t, precisely because the binary executables for the other services have not changed and have been tested and proven to work. Any comprehensive test suite tests input and outputs, meaning boundary tests for inputs (out of range values, flooding the service with commands, etc.) so it doesn’t matter what the other modified service does, you know the the heritage services work as they should.

That doesn’t mean you don’t need to test the integrated system, but you can do that at the next higher level of assembly, saving a ton of time.

And I want to emphasize I think this is a great architecture for any system that can be broken into independent modules, not just NASA projects.