3 ms·
Having lots of small repos also generates overhead they need to be checked out separately, tagged individually, built individually, etc. The reason that this i
by jillesvangurp 3y ago
Having lots of small repos also generates overhead they need to be checked out separately, tagged individually, built individually, etc.
The reason that this is a bad April first joke is that the idea actually has merit. Google runs their company like this. The unthinkable bit is not doing this technically but Debian rearchitecting the way it works. Doing this with Git is a separate topic. It's probably not great for this. But mono repos at this scale are not impossible.
- SOLAR_FIELDS 3y agoThere was an article by some well known CTO that hits the nail on the head for me. Essentially they said that monorepo makes sense at small scale and enormous scale (eg Google) but anywhere in between that microservices make more sense. Knowing when you are going to be at those scales is key. In any event, as has been alluded to in this thread already, any complaint about microservices vs monorepo and switching between them is almost always a tooling complaint. Companies will invest in one of these “philosophies” around code organization then won’t take the time to build the appropriate tooling to support them and then three years down the road some enterprising architect will switch from one to the other and the cycle begins anew