4 ms·

Agree with the spirit of this observation, but at the scale we work with at Uber, at comes a point in which "too much" decoupling starts biting you in the ass.

Agree with the spirit of this observation, but at the scale we work with at Uber, at comes a point in which "too much" decoupling starts biting you in the ass. Sounds kind of bizarre actually, but this is a particular characteristic of a microservice architecture after it's reached a certain amount of elements in the network and certain amount of complexity. I can't imagine deploying a functionality that needs to interact with 20 other services, if I can't have some zero-cost assurances like Go's typing and having all IDL available at developing time. This is of course is even better if at compile time I can check all contracts are still honoured. Monorepo is a really "cheap" way of getting all this for, close to, free.

preseinger 4y ago
> I can't imagine deploying a functionality that needs to interact with 20 other services . . . If a product feature X can't be delivered without changes to 20 services, the architecture is too granular.
- sebastialonso 4y ago
  Agreed, but I didn't mentioned changes, I mentioned interaction. Reading data in this case.
  - preseinger 4y ago
    You're right that monorepos make it easy for contracts that define wire protocols to stay "in sync" between services, at the code level. But the ~main whole point of defining distinct services which exist on different ends of a wire is so that they don't need to stay in sync at the code level! As you say, a service implements a contract, written as an IDL or a JSON schema or informal convention or whatever, in order to express a promise to consumers. That promise needs to be kept as long as any consumer relies on it. If your search service publishes a protobuf that has a service definition called e.g. SearchV1, then your search service is absolutely obliged to keep supporting that SearchV1 service until it's no longer used by anyone. If this isn't the case, and you can deploy changes to a service that violate the wire-protocol contract you establishes with your consumers, then this is a problem. And it's easy to do. I find that many programmers don't fully understand the weight and implications of the interface they define between client and server.
throwdbaaway 4y ago
Your example is the clearest indication in the whole discussion that Uber has a distributed monolith.

preseinger 4y ago

> I can't imagine deploying a functionality that needs to interact with 20 other services . . . If a product feature X can't be delivered without changes to 20 services, the architecture is too granular.

sebastialonso 4y ago
Agreed, but I didn't mentioned changes, I mentioned interaction. Reading data in this case.
- preseinger 4y ago
  You're right that monorepos make it easy for contracts that define wire protocols to stay "in sync" between services, at the code level. But the ~main whole point of defining distinct services which exist on different ends of a wire is so that they don't need to stay in sync at the code level! As you say, a service implements a contract, written as an IDL or a JSON schema or informal convention or whatever, in order to express a promise to consumers. That promise needs to be kept as long as any consumer relies on it. If your search service publishes a protobuf that has a service definition called e.g. SearchV1, then your search service is absolutely obliged to keep supporting that SearchV1 service until it's no longer used by anyone. If this isn't the case, and you can deploy changes to a service that violate the wire-protocol contract you establishes with your consumers, then this is a problem. And it's easy to do. I find that many programmers don't fully understand the weight and implications of the interface they define between client and server.

throwdbaaway 4y ago

Your example is the clearest indication in the whole discussion that Uber has a distributed monolith.