3 ms·

Interesting paper. > The programming model enables a developer to write a distributed application as a single program, where the code is split into modular uni

Interesting paper. > 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/ 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.

Aqueous 3y ago
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.
- lunarcave 3y ago
  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.
  - Aqueous 3y ago
    It's not applicable at all once you get beyond a few teams. A mono-repo makes decisions for your teams.
    - lunarcave 3y ago
      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 https://en.wikipedia.org/wiki/Monorepo
      - deleted 3y ago
        [deleted]
      - Aqueous 3y ago
        Those companies largely made the decision for monorepos before there was tooling to support a proper multi-repo existence.

Aqueous 3y ago

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.

lunarcave 3y ago
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.
- Aqueous 3y ago
  It's not applicable at all once you get beyond a few teams. A mono-repo makes decisions for your teams.
  - lunarcave 3y ago
    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 https://en.wikipedia.org/wiki/Monorepo
    - deleted 3y ago
      [deleted]
    - Aqueous 3y ago
      Those companies largely made the decision for monorepos before there was tooling to support a proper multi-repo existence.