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.
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.
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.
> The programming model enables a developer to write a distributed application as a single program, where the code is split into modular units called components (Section 3). This is similar to splitting an application into microservices, except that microservices conflate logical and physical boundaries.
I definitely do see the merits to this. The fact that we always see logical separation of services resulting in split codebases did never sit right with me.
We've been trying to solve the same problem, but albeit in a different way here: https://docs.differential.dev/getting-started/thinking/ (Disclaimer: I'm the founder - would love to collaborate)
Trying to answer the question of - can you build your entire stack in a monolithic way, but split it to domain-driven services at the runtime?
That way, you get the developer experience of co-location, and runtime benefits of isolated workloads. The service definitions are malleable and can evolve as the complexity increases.