The largest benefit of microservices has always been lifecycle management, and "clear interfaces" in "modular monoliths" does not in fact solve that. If you update the logging library in a monolith, everyone takes that updates even if it breaks half the teams.

That's a "large" organization problem. But large is actually, not that big (about 5-10 scrum teams before this is a very large problem).

It also means on critical systems separating high risk and low risk changes are not possible.

Like all engineering decisions, this is a set of tradeoffs.

> The largest benefit of microservices has always been lifecycle management, and "clear interfaces" in "modular monoliths" does not in fact solve that.

What lifecycle are we really talking about? There are massive monoliths - like the Linux kernel or PostgreSQL - with long lifespans, clear modularity, and thousands of contributors, all without microservices. Lifecycle management is achievable with good architecture, not necessarily with service boundaries.

> If you update the logging library in a monolith, everyone takes that updates even if it breaks half the teams.

This is a vague argument. In a microservice architecture, if multiple systems rely on the structure or semantics of logs — or any shared behavior or state - updating one service without coordination can just as easily break integrations. It’s not the architecture that protects you from this, but communication, discipline, and tests.

> It also means on critical systems separating high risk and low risk changes are not possible.

Risk can be isolated within a monolith through careful modular design, feature flags, interface boundaries, and staged rollouts. Microservices don’t eliminate risk - they often just move it across a network boundary, where failures can be harder to trace and debug.

I’m not against microservices. But the examples given in the comment I responded to reflect the wrong reasons (at least based on what I’ve seen in 15+ years across various workplaces) for choosing or avoiding a microservice architecture.

Microservices don’t solve coupling or modularity issues — they just move communication from in-process calls to network calls. If a system is poorly structured as a monolith, it will likely be a mess as microservices too — just a slower, harder-to-debug one.

>Most “benefits” assumed from separation can be achieved with clear interfaces and modular monoliths, without the cognitive and operational tax microservices impose.

Perhaps yes. Every situation should be evaluated on merits. This came across that there is also an assumption that we didn't try other solutions first - we absolutely did. Microservice is the best solution to solving the problems we needed solved in this case. Even better than modular monolith with clear interfaces.

>without the cognitive and operational tax microservices impose

When done correctly, I don't think there is a tax. Most operational questions should be automated away once discovered. The only 'tax' is that it lives separately from the larger application and is deployed independently, but I haven't seen in practice this add any notable overhead.

>Preventing misplaced logic is a matter of good code structure, well defined software development processes and team discipline

All true, and a microservice can aid all of these things too, but isn't the solution you should reach for when solving for these things and these things alone in my opinion. That said, myself and others have observed there is time saved on enforcing discipline around this issue once we separated the code away from the main application. I can't deny that hasn't been a good thing, because it has. It would be leaving information out about the benefits we'v experienced, and I see no reason to do that.

All told, completely dismissing the value of microservices as a potential solution is no different than completely dismissing other solutions in favor of microservices. Things have their place, there are pros and cons to them, and should be evaluated relative to their merit for the situation.

You may find you never implement microservices, or implement very few, or perhaps the needs of an organization is as such that its a pattern used most of the time, but the technical merits of doing so - with any decision of this nature, not limited to microservices - should have a backing justification that includes why other solutions don't fit

> Every situation should be evaluated on merits. This came across that there is also an assumption that we didn't try other solutions first - we absolutely did.

I completely agree. But this a little bit contradicts with your original comment that caught my eye:

> In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service.

A rule of thumb is, by nature, a generalization — it simplifies decision making through heuristics. Benefits on the other hand always subjective, they can be interpreted in a given context.

And based on my experience, there will always be some benefits that can be used to justify factoring something out into a separate service. The challenge is that it's often easy to overemphasize those benefits, even when they don't outweigh the downsides. Your example with the auth service and the added friction is, in my view, a good illustration of a justification that might sound reasonable but can lead to unnecessary complexity. (Just to be clear, my intent here isn't to judge your decisions - I understand these trade-offs are often nuanced - and that's why again there is no good rule of thumb for this)

>I completely agree. But this a little bit contradicts with your original comment that caught my eye:

Its a good rule of thumb that you may want to evaluate if a microservice is appropriate. Thats the point in context[0]. If you think it might be a relevant solution, that is a pretty good heuristic that evaluating it may be worth the time.

What I seem to be coming up against when discussing this is people conflate worthwhile evaluation with worthwhile solution. Thats where the nuance and details need to live is in solution discovery, but how do you arrive at the right solution if you don't first evaluate what solutions might fit a given problem?

I stand by it being a good rule of thumb. If you think there are actual benefits - not perceived, but quantifiable benefits - of something being a standalone independent service, you might have a case for a microservice. I feel its a good heuristic for narrowing solution evaluation.

It doesn't equate to saying microservice is the solution if it meets that one criteria, only don't rule it out.

>And based on my experience, there will always be some benefits that can be used to justify factoring something out into a separate service. The challenge is that it's often easy to overemphasize those benefits, even when they don't outweigh the downsides. Your example with the auth service and the added friction is, in my view, a good illustration of a justification that might sound reasonable but can lead to unnecessary complexity.

Bias is hard to overcome. Technical decision makers need to be keenly aware of this. I wish it was easier to identify when this comes into the situation as it plays a bigger role in all this than is often realized. I go to great lengths to validate my thoughts when making big technical decisions for this reason, and deciding on something like this is a big technical decision that deserves that approach, in my opinion.

One good quality of a good technical decision maker is taking the time to quantify why its a good solution and why other solutions are not, and that must hold up to technical scrutiny of your peers. This challenges any assumptions missed. Ideally, your peers should be able to see through anything that wasn't given enough evaluation, like if the benefits of doing something is overemphasized.

>good illustration of a justification that might sound reasonable but can lead to unnecessary complexity.

I agree, which is why I state elsewhere that it shouldn't be used solely for this purpose, but I'm not going to leave out a real benefit we saw. If there is a persistent organizational problem that engineers seem to want to put code inside of something that is in broader context inappropriate or adds complexity where it shouldn't, you may benefit from such friction and its okay to evaluate that aspect too.

[0]: By which I mean in the context of the article, which I think dismisses microservices as a potential solution with prejudice

> By which I mean in the context of the article, which I think dismisses microservices as a potential solution with prejudice

> What I seem to be coming up against when discussing this is people conflate worthwhile evaluation with worthwhile solution.

> It doesn't equate to saying microservice is the solution if it meets that one criteria, only don't rule it out.

I read the article, it's not against microservice architecture itself, but points out that you shouldn't treat them as a starting point or a best practice.

There is even a section named "When Microservices Do Make Sense". It also highlights examples where microservices make sense ("Their post is a good example of how microservices can work when you have the organizational maturity and operational overhead to support them."), so I really do not see where does anyone rule out, dismiss, come up against anything.

I somewhat understand and agree what you are trying to argue against, but that's definitely not in this article.

> Its a good rule of thumb that you may want to evaluate if a microservice is appropriate.

This is too general to be practically useful — it applies to almost everything in life.