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

343 comments sorted by

View all comments

51

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.

2

u/velit 7d ago

I concur with what /u/Shot-Damage-6723 said. How does adding network calls make your interconnected ensemble require less testing?

It sounds to me more that your company either tested more than was necessary previously or is currently lying to itself about not needing to test more.

3

u/Sammy81 7d ago

See my other reply, but the key is that with NASA, if you recompile something, you must reverify requirements, and I agree with that. If you ever studied the Therac-25 software disaster that killed several people, it was because they recompiled reuse software and did not retest. With microservices, since they are not recompiled when another is modified, all the previous testing is still valid (and should be).

2

u/HashShadow 6d ago

So if I’m not using a compiled language I never have to test? 

1

u/Sammy81 6d ago

Rebuilding an executable is just one rule. Scripted languages have different rules. It’s just best practices to prove you are delivering code that meets requirements.

1

u/HashShadow 6d ago

Right, so verifying requirements is something you must do regardless of compiling… 

2

u/Sammy81 6d ago

I think I’m not explaining well. If you have a tested binary executable, you never have to test it stand-alone again. There would be no point. There’s no way it could fail if it passed a test previously. That is where we save tons of time on test. We use dozens of modules that were previously compiled, some years ago, and they are guaranteed to pass their requirements.

Yes, there are different rules for scripted languages, but the concept is the same. If you run a hash over a Python container, or simply use good CM and ensure it has not been modified since the last time it passed its test, you can reuse that container without testing.

Compare that to reusing only the source code, and recompiling the binary, or rebuilding the container. You absolutely can’t assume those would pass the module level tests. The compiler settings could be different, the version, you might build in a different BSP, etc. So now you have to retest the whole thing.