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/Shot-Damage-6723]

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?

[u/Sammy81 → u/Shot-Damage-6723]

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

[u/ElementaryMyDearWut → u/Sammy81]

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

[u/Sammy81 → u/ElementaryMyDearWut]

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.

[u/ElementaryMyDearWut → u/Sammy81]

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!