Comment by jedberg | Hacker News Reader

Comment by jedberg | Hacker News Reader

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.

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.

> 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.

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

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.

The big thing about monorepos in this case is making a change atomic across a set of projects. Multirepos can't do this 99% of the time and often add a lot more procedure to something close. It's inherently async.

> The big thing about monorepos in this case is making a change atomic across a set of projects.

The thing microservices is supposed to solve is eliminating the need to make atomic changes across services. There is an inherent overhead in doing that, like making your service support both new and old APIs as long as any service exists using the old API. This is the cost of microservices.

The world isn't just backend. There are mobile projects, games, native desktop apps which act together as a suite and web frontends. Also microservices bring up their own host of issues and extra labor. Both are essentially the semantic versioning library update problem, and when you need to propagate a breaking change it create a whole bunch more labor that is significantly reduced in a monorepo vs. a multirepo/microservice world.

The tradeoff is you need to invest into repo scaling, much like a backend service that needs to invest in scaling itself too.

I haven’t worked at a Big Tech monorepo place, but I hope/assume that in the service dependency case, you would touch both in one changeset and the deploy tooling understands the dependency tree and orders the deployments correctly. Without that i agree its the polyrepo approach just with all PRs in the same repo instead of multiple.

In the library scenario, I know tooling like bazel ensures that’s one changeset, not 3+. Tests run for both the changed library and all consumers of it in the same pass. You’re right that it might loop in others for review who weren’t expecting it, but i think that’s the same in a polyrepo approach.

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.

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".

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.

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

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.

Reply on news.ycombinator.com