3 ms·

They have their place. In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service. For example, we have a authen

They have their place. In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service. For example, we have a authentication microservice at work. It makes sense that it lives outside of the main application, because its used in a multiple different contexts and the service boundary allows for it to be more responsive to changes, upgrades and security fixes than having it be part of the main app, and it deploys differently than the application. It also adds enough intentional friction that we don't accidentally put logic where it doesn't belong as part of the user authentication process. It has helped keep the code focused on only primary concerns. That said, you can't apply any of these patterns blindly, as is so often the case. A good technical leader should push back when the benefits don't actually exist. The real issue is lack of experience making technical decisions on merits. This includes high level executive leaders in the organization. At a startup especially, they are still often involved in many technical decisions. You'd be surprised (well maybe not!) how the highest leadership in a company at a startup will mandate things like using microservices and refuse to listen to anything running counter to such things. [0]: https://en.wikipedia.org/wiki/Rule_of_thumb https://en.wikipedia.org/wiki/Rule_of_thumb

esafak 1y ago
I don't think this merited a wiki link :)
- no_wizard 1y ago
  Its an international forum, there may be at least 1 person who hasn't encountered this colloquialism before. It hinders nothing yet may be informative to someone who's unfamiliar.
- nazgulsenpai 1y ago
  Perhaps in consideration of a non-native English speaker who might not understand the phrase.
- Akronymus 1y ago
  And I dont see how the link detracts from the post at all. For ESL people, like me, it can be quite helpful to have such a link. (i find myself looking up such phrases quite often)
zsoltkacsandi 1y ago
Most “benefits” assumed from separation can be achieved with clear interfaces and modular monoliths, without the cognitive and operational tax microservices impose. > It also adds enough intentional friction that we don't accidentally put logic where it doesn't belong as part of the user authentication process. Preventing misplaced logic is a matter of good code structure, well defined software development processes and team discipline - not something that requires splitting into a separate microservice, and definitely not something that you want to solve on system architecture level.
- no_wizard 1y ago
  >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

esafak 1y ago

I don't think this merited a wiki link :)

no_wizard 1y ago
Its an international forum, there may be at least 1 person who hasn't encountered this colloquialism before. It hinders nothing yet may be informative to someone who's unfamiliar.
nazgulsenpai 1y ago
Perhaps in consideration of a non-native English speaker who might not understand the phrase.
Akronymus 1y ago
And I dont see how the link detracts from the post at all. For ESL people, like me, it can be quite helpful to have such a link. (i find myself looking up such phrases quite often)

zsoltkacsandi 1y ago

Most “benefits” assumed from separation can be achieved with clear interfaces and modular monoliths, without the cognitive and operational tax microservices impose. > It also adds enough intentional friction that we don't accidentally put logic where it doesn't belong as part of the user authentication process. Preventing misplaced logic is a matter of good code structure, well defined software development processes and team discipline - not something that requires splitting into a separate microservice, and definitely not something that you want to solve on system architecture level.

no_wizard 1y ago
>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