Hacker News Reader

Comment by jedberg | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com