3 ms·
This is a common mis-conception that the application design and/or deployment is tied to the repo or repos. They are completely orthogonal. Micro services can b
by slively 4y ago
This is a common mis-conception that the application design and/or deployment is tied to the repo or repos. They are completely orthogonal. Micro services can be done in mono or multi repo. A distributed monolith can be done in mono or multi repo. Either can also be done without version control.
- likortera 4y agoI'm saying using BOTH monorepo AND microservices is a clear signal you're building a distributed monolith. What you say is also true
- slively 4y agoAh I see, I could definitely see that being a useful heuristic. Also it seems like the origins of micro services comes from places like Google that use a mono repo. The proof is in the pudding in the end I suppose.
- preseinger 4y agoMicroservices are meant to decouple teams at both the deployment (runtime) level _and_ the source (repo) level. Microservices + monorepo is at least at some level self-subversive.
- sebastialonso 4y agoAgree 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 agoAgreed, but I didn't mentioned changes, I mentioned interaction. Reading data in this case.
- preseinger 4y agoYou'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 agoYour example is the clearest indication in the whole discussion that Uber has a distributed monolith.