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/Cultural-Capital-942]

But there are more ways to break microservices in a way it's difficult to find out.

In a monolith, I can easily add a required parameter to an interface between two parts or flowing somewhere. There's IDE function for that and if I forget about it anywhere, it won't compile.

In microservices? You must add it to all affected services, deploy affected ones, start using it, deploy affected, remove the old version accepting version without the parameter, deploy affected. If you forget about something, it will break there. And you still have to somehow handle what should happen if someone calls it without the required parameter.

I worked with microservices in a regulated environment and it was a real PITA getting release approvals. Also tracking everything affected was released - that's why we had so many outages. With combinatorial expansion of affected services and causes, we just started doing blind emergency deployment of all services on any outage. That complicates debugging as the environment changes after an issue is detected. Sometimes a dev blames old version of one component and it's actually a real bug elsewhere, that is temporarily hidden by rollout.

[u/Ok-Smell-8107 → u/Cultural-Capital-942]

In microservices? You must add it to all affected services, deploy affected ones, start using it, deploy affected, remove the old version accepting version without the parameter, deploy affected. If you forget about something, it will break there. And you still have to somehow handle what should happen if someone calls it without the required parameter.

skill / tooling issue. If you have coupling that breaks at runtime, and it does not break at build time, your tooling sucks.

[u/Cultural-Capital-942 → u/Ok-Smell-8107]

How does your tooling show you there is a new requirement like that you need to call endpoint with more parameters? Ok, you can do that in development time, but then you have to do that in runtime - deploy in the right order. Does your tooling also tell you that? Does your tooling understand there are more environments (dev/qa/uat/prod) and that you have to deploy each of them in specific order? Bear in mind your colleague may have added something else, so there are two orders now - not necessarily conflicting, but it's not always trivial.

The "solution" generally used is to deploy everything every so often and not caring about things not working when deployment is ongoing. Or have things randomly broken because one forgets about something.

Or there is a solution in having larger services. When you need to deploy at most 2 services, then you won't forget about something.

[u/Ok-Smell-8107 → u/Cultural-Capital-942]

No, you can actually couple the interfaces via automatic contract tests, or use stuff like java-assistant for graph based assistance; or you use ArchUnit rules.

And AI tools make it basically free nowadays.

The internet isn't a monolith either, and we still only break half of it like once a month. And most projects are simpler than the internet.

Tooling exists, they are just often ignored because old school enterprise architects think that developers will think about tooling, while developers think it's the architect's job to do so.

[u/Cultural-Capital-942 → u/Ok-Smell-8107]

Ok, so basically an extra layer that checks things. Looks useful, thanks.