Re:Should that be a microservice? Factors to keep in mind
by jayd16 on Saturday April 20, 2019 @08:54PM
(#19709895)
>The overhead of maintaining multiple services, repos, CIs and so on is not trivial for s team of 10 people or less.
This is why the big guys use mono repos. It makes it trivial to split off services from a code perspective. You still need to manage the ops but if it's code that could have run in another service the ops is mostly a copy/paste of an existing deployment.
As for knowing where the service boundry is, that's something that can evolve just as easily as is does in a monolith codebase. Sometimes your class structure is right and sometimes you need to retool it. It shouldn't be the end of the world to update an internal service.
This is why the big guys use mono repos. It makes it trivial to split off services from a code perspective. You still need to manage the ops but if it's code that could have run in another service the ops is mostly a copy/paste of an existing deployment.
As for knowing where the service boundry is, that's something that can evolve just as easily as is does in a monolith codebase. Sometimes your class structure is right and sometimes you need to retool it. It shouldn't be the end of the world to update an internal service.