undefined | Better HN

0 pointszsoltkacsandi1y ago0 comments

> 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)

0 comments

no_wizard1y ago

>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

zsoltkacsandiOP1y ago

> 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.

j / k navigate · click thread line to collapse