Has anyone tried something like Polylith which lets you build all your code like normal functions for local dev and testing and then seemlessly pull out parts to network services as needed?
Microservices are a tax your startup probably can't afford
21–30 of 272 posts
Re: Microservices are a tax your startup probably can't afford
#22They 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…
I don't think this merited a wiki link :)
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.
Re: Microservices are a tax your startup probably can't afford
#23Totally agree. Micro services unnecessarily makes thing complicated for small teams. IMHO it solves the problem of velocity ONLY when a large engineering team is slowed down due to too much release & cross cutting dependencies on a monolith. Although I see people solving with modular monoliths, merge queues and CODEOWNERS effectively.
Few cases where microservices makes sense probably when we have a small and well bounded use-case like webhooks management, notifications or may be read scaling on some master dataset
Re: Microservices are a tax your startup probably can't afford
#24They 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…
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.
Re: Microservices are a tax your startup probably can't afford
#25Totally agree. Micro services unnecessarily makes thing complicated for small teams. IMHO it solves the problem of velocity ONLY when a large engineering team is slowed down due to too much release & cross cutting dependencies on a monolith. Although I see people solving with modular monoliths, merge queues and CODEOWNERS effectively. Few cases where microservices makes sense probably when we have a small and well bo…
Can you elaborate a bit on codeowners, I've not heard of that kind of solution before.
Re: Microservices are a tax your startup probably can't afford
#26I know about a org with ~2-3 devs who decided microservices would be cool. I warned not to go that way because they would surely face delivery and other issues which they wouldn't have when building the solution based on a architecture archetype which could be a better fit for the team and solution, which I evidently decided should be a modular monolith. (the codebase at that point was already a monolith, in fact, bu…
> 3 years later and they are still fighting delivery and other issues
Having added a fancy new technology and a "successful" project to their resume, they're supposed to move on to the next job before the consequences of their actions are fully obvious.
Re: Microservices are a tax your startup probably can't afford
#27[deleted]
Re: Microservices are a tax your startup probably can't afford
#28[dead]
Re: Microservices are a tax your startup probably can't afford
#29They 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…
I don't think this merited a wiki link :)
Perhaps in consideration of a non-native English speaker who might not understand the phrase.
Re: Microservices are a tax your startup probably can't afford
#30I know about a org with ~2-3 devs who decided microservices would be cool. I warned not to go that way because they would surely face delivery and other issues which they wouldn't have when building the solution based on a architecture archetype which could be a better fit for the team and solution, which I evidently decided should be a modular monolith. (the codebase at that point was already a monolith, in fact, bu…
Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.