2023 Was a Turning Point for Microservices

Re:2023 Was a Turning Point for Microservices by Aqueous on Thursday January 04, 2024 @05:24PM (#38873140)

I actually don’t want the developer experience of co-location. There are millions of things that are totally irrelevant happening in my company’s (thousands of engineers) monolith. The noise in the commit log is considerable. Isolated repos are smaller, and reduce useless coupling.

[ Parent | on HN ]

Re:2023 Was a Turning Point for Microservices by lunarcave on Thursday January 04, 2024 @05:44PM (#38873326)

I get that it's not a universally applicable solution. I guess at a certain point of scale your organisation would grow out of complete co-location.

But I don't think we have to go with the 100% co-location approach as well. A large monorepo could be organized into domain specific mini-monorepos with co-location benefits.

[ Parent | on HN ]

Re:2023 Was a Turning Point for Microservices by Aqueous on Thursday January 04, 2024 @07:50PM (#38874323)

It's not applicable at all once you get beyond a few teams.

A mono-repo makes decisions for your teams.

[ Parent | on HN ]

Re:2023 Was a Turning Point for Microservices by lunarcave on Thursday January 04, 2024 @11:44PM (#38875761)

I think Google, Meta, Microsoft, Twitter, Uber [1] and the thousands of engineers that these companies (and many other companies) employ, would disagree with you.

[1] https://en.wikipedia.org/wiki/Monorepo

[ Parent | on HN ]

Re:2023 Was a Turning Point for Microservices by Aqueous on Monday January 08, 2024 @07:59PM (#38920834)

Those companies largely made the decision for monorepos before there was tooling to support a proper multi-repo existence.

[ Parent | on HN ]