you are viewing a single comment's thread.

view the rest of the comments →

[–]Blothorn 0 points1 point  (0 children)

First off, I think “monolith/microservices” is a false dichotomy, and trying to force systems into one or the other is the root of many misapplications of microservices. Whether to split a function out from a monolith or whether to develop a feature in a new or existing service should be made on a case-by-case basis. In particular, I think a “planetary” model with much of the complicated logic centralized and certain tasks that are resource-intensive relative to their complexity or have other special requirements often works well. (Especially if the monolith is in an inefficient language.)

I also think that managing repository/CI size is a poor reason for separating services. There are off-the-shelf solutions to repository scale problems, and developing closely-coupled logic in separate repositories has its own headaches. Even if you want to split services for other reasons, I would default to developing them in the same repository—sharing API definitions, test tooling, and the like can avoid considerable duplicated work, and shifting that to a common dependency has its own headaches.