3 ms·

I believe that the solution to the coordination problem is good monorepo tooling (like the OP) plus AI to understand the whole codebase and help the engineers u

by jedberg 2mo ago

I believe that the solution to the coordination problem is good monorepo tooling (like the OP) plus AI to understand the whole codebase and help the engineers understand how their part fits in. I was one of the biggest proponents of microservices, going so far as to traveling around the world spreading the gospel of microservices keynoting large tech conferences. I believed that microservices were the best solution to scaling large teams of developers, so that small teams could work on small problems, where the API was the only contract between them. But even then I cautioned that the overhead made it not worthwhile for small teams -- that it was a solution to the coordination problem for large organizations. And that Google was not a counterexample because they had spent so many resources on their monorepo tooling. But there is a new factor in town that changes the calculus: AIs can grok monorepos much easier than a cluster of microservices. AIs change the calculus here. They allow the developer to work successfully in even the largest monorepos, and the AIs themselves will give better results when all of the code is in one place.

consensus1 2mo ago
Microservices is a deployment strategy. Monorepo is a code organization strategy. They are not mutually exclusive.
- jedberg 2mo ago
  While you are technically correct (the best kind of correct), I would challenge you to find an organization that is doing the monorepo/microservice combo correctly. And what I mean by that is with microservices, the API is the only contract. Every service should be deployable independently. If you have a monorepo, you're almost certainly violating that somewhere, using a shared library, or a shared database, or even just blocking deployment because some other service has turned the repo red.
  - claytonjy 2mo ago
    [dead]
yissachar 2mo ago
You can have microservices while still using a monorepo. They are still useful for creating service topology that can segment scaling and permissions, though I think people get carried away in the number of services created. I think the eventual sweet spot will be monorepos that have good modular boundaries, and dynamically adjusting service topology that doesn't rely on pre-committed decisions on what code lives in a "service".
fcarraldo 2mo ago
IME, AI does find established patterns more quickly a in monorepo (sometimes the ones you want, sometimes the ones you don't) - but at the cost of an enormous overhead tax you pay on input token cost. Giving agents pointers to the right patterns, libraries and services helps avoid expensive grep goose chases, but if you're already curating the input you can do the same thing with small repositories.
mnahkies 2mo ago
I'm going to play devil's advocate here. As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down). As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness the ability to drop into each polyrepo as required (and give it the ability to access said documentation). The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. Admittedly the way I'm using agents at the moment is more repo orientated where it's sandboxed to a single repo, but conceptually I think polyrepo microservices could end up being a sweet spot.
- jedberg 2mo ago
  > The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time. Which is why microservices are best for larger organizations, because it reduces coordination between dev groups.
  - claytonjy 2mo ago
    if service A calls service B, and service B adds a new endpoint, or a new optional argument, service A needs an update to take advantage of it if a library is used by multiple services, and gets an important bug fix, each service using the library needs to update to get the fix these are sequences of changes, not literally at the same time or requiring deployment coordination, but when this happens a lot people start asking about monorepos
    - jedberg 2mo ago
      But a monorepo wouldn't make any of that easier. You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo. A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.
mac-mc 2mo ago
IMO AI agents harnesses (claude code, codex, etc) haven't added monorepo features yet as of a couple of months ago and thats what makes them painful. Basic things like, only apply these skills to the subdir that the .agents/skills directory exists in would go a long way. Or even reading the skills in a subdir .agents/skills directory. Or the ability to specify the basic monorepo custom VCS and other actions in a way that isn't limited to fragile skills and AGENTS.md specs that can get forgotten or unused as the context windows grows in a session and so on.

by jedberg 2mo ago

consensus1 2mo ago

Microservices is a deployment strategy. Monorepo is a code organization strategy. They are not mutually exclusive.

jedberg 2mo ago
While you are technically correct (the best kind of correct), I would challenge you to find an organization that is doing the monorepo/microservice combo correctly. And what I mean by that is with microservices, the API is the only contract. Every service should be deployable independently. If you have a monorepo, you're almost certainly violating that somewhere, using a shared library, or a shared database, or even just blocking deployment because some other service has turned the repo red.
- claytonjy 2mo ago
  [dead]

yissachar 2mo ago

You can have microservices while still using a monorepo. They are still useful for creating service topology that can segment scaling and permissions, though I think people get carried away in the number of services created. I think the eventual sweet spot will be monorepos that have good modular boundaries, and dynamically adjusting service topology that doesn't rely on pre-committed decisions on what code lives in a "service".

fcarraldo 2mo ago

IME, AI does find established patterns more quickly a in monorepo (sometimes the ones you want, sometimes the ones you don't) - but at the cost of an enormous overhead tax you pay on input token cost. Giving agents pointers to the right patterns, libraries and services helps avoid expensive grep goose chases, but if you're already curating the input you can do the same thing with small repositories.

mnahkies 2mo ago

I'm going to play devil's advocate here. As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down). As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness the ability to drop into each polyrepo as required (and give it the ability to access said documentation). The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. Admittedly the way I'm using agents at the moment is more repo orientated where it's sandboxed to a single repo, but conceptually I think polyrepo microservices could end up being a sweet spot.

jedberg 2mo ago
> The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time. Which is why microservices are best for larger organizations, because it reduces coordination between dev groups.
- claytonjy 2mo ago
  if service A calls service B, and service B adds a new endpoint, or a new optional argument, service A needs an update to take advantage of it if a library is used by multiple services, and gets an important bug fix, each service using the library needs to update to get the fix these are sequences of changes, not literally at the same time or requiring deployment coordination, but when this happens a lot people start asking about monorepos
  - jedberg 2mo ago
    But a monorepo wouldn't make any of that easier. You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo. A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.

mac-mc 2mo ago

IMO AI agents harnesses (claude code, codex, etc) haven't added monorepo features yet as of a couple of months ago and thats what makes them painful. Basic things like, only apply these skills to the subdir that the .agents/skills directory exists in would go a long way. Or even reading the skills in a subdir .agents/skills directory. Or the ability to specify the basic monorepo custom VCS and other actions in a way that isn't limited to fragile skills and AGENTS.md specs that can get forgotten or unused as the context windows grows in a session and so on.