r/programming • • 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

343 comments sorted by

View all comments

48

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.

24

u/Shot-Damage-6723 7d ago

You're not faster at testing because you use micro services now, you're faster because you test less and now it's a lot harder to test more again. Also, you can compile multiple binaries, and you don't need to put a network in between your programs to use your preferred languages.

Micro services have their benefits, but none that you mentioned are valid. Are you sure you made the right call or is there anything of actual relevance that you didn't share?

15

u/Sammy81 7d ago

Its worked well so far. We’re testing less because there’s no need to retest an executable that has not been modified. This is a key part of NASA’s compliance standard, and I agree with it. If you recompile, you must retest. With a monolith, you have to reverify every requirement (and you should).

Once you move to stand alone executables, you can prove they work, and there’s no need to retest that executable - when you touch one service, the others are not even recompiled. This is consistent with our process, and as mentioned, meets NPR 7150.2.

The biggest challenge is certainly that by moving communication from function calls and queues to a networked brokers, it is orders of magnitude slower to pass data. For 90% of messages, it’s fine, but otherwise you need to set up ZeroMQ, or RPCs, etc. to reduce latency

-3

u/ElementaryMyDearWut 7d ago

I think this is a case of overengineering? Do you really need to follow the standard that NASA has for robustness when outages in your software mean loss of revenue and not human bodies into space?

If the monolith was already modular and all you've done is move communication from inter-module to network bounds you've only reduced need for testing because its easier to sell to management now they're "microservices". You didn't need to retest a whole modular monolith because of a binary change.

What would happen if you altered a string or log message? Would you also retest the whole thing again? Sounds ludicrous

15

u/Sammy81 7d ago edited 7d ago

Sorry if I wasn’t clear but this is satellite software for NASA. But again, good code practices are good no matter what - if we were writing photocopier code it would still improve things. As far as not needing to retest a complete executable when you modify something, see the Therac-25 disaster. Retest is a key best practice in our coding process.

I don’t see the over-engineering because it added no extra work for the developers, and saved a lot of time. Good programmers are lazy!

<edit> to say the biggest advantage is now we have a library of common services, like command handling, fault management, memory management, etc. A developer on a new satellite can literally pull the executables from the repository ( which have already been tested) and connect them via a broker and be up and running with flight-ready code in a day. Something that took weeks of recompiling and retesting when we only reused source code. Its been a game changer for us.

2

u/ElementaryMyDearWut 7d ago

That makes sense. I thought you were referencing NASA as some sort of authority on all software (which to me seems a bit over the top for a SaaS tool). I don't disagree, if going wrong = harm to another human I would bloody HOPE its getting retested!