4 ms·

> In a shared monolith however 0 people own it because everyone owns it and the repo becomes a disaster faster than you can say "we need enterprise caching". *

by jmull 3y ago

> In a shared monolith however 0 people own it because everyone owns it and the repo becomes a disaster faster than you can say "we need enterprise caching". * I give two teams one repo each and tell each one: "This is your repo, keep it clean." -or- * I give two teams one folder each in a repo and tell each one: "This is your folder, keep it clean." If you've got a repo or folder (or anything else) that no one is responsible for, that's a management problem, and micro services won't solve it. Repos (and folders) don't really have anything to do with organizing a complex system of software -- they are just containers whose logical organization should follow from the logical organization of the system. Microservices back you into position where when the code of one team to calls the component of another team, it has to be high-latency, fault-prone, low-granularity, config-heavy. Some stuff falls the way anyway, so no problem in those case, but why burn that limitation in to your software architecture from the start? Just so you don't have to assign teams responsibility for portions of a repo?

leeoniya 3y ago
i think doing releases, deployments, and rollbacks is trickier in a monorepo. with multiple services/repos, each team can handle their own release cycles, on-call rotation, and only deal with the bits, tests, and failures they wrote. you lose some CPU/RAM/IO efficiency, but you gain autonomy and resilience, and faster time to resolution. https://blog.nelhage.com/post/efficiency-vs-resiliency/ https://blog.nelhage.com/post/efficiency-vs-resiliency/ e.g. at Grafana we're working through some of these decoupling-to-microservices challenges, because the SREs that deploy to our infra should not need to deal with investigating and rolling back a whole monolith due to some regression introduced by some specific team to a core datasource plugin, or frontend plugin/panel. the pain at scale is very real, and engineering hours are by far more expensive than the small efficiency loss you get by over-provisioning the metal a bit.
- jmull 3y ago
  I didn't mean to say there are no reasons to have separate repos, just more responding to the post above mine. But I will note that almost all the benefits listed aren't specific to micro services. (Also, to me, it's flawed that a dependency can really push to production without coordination. At the least, dependent components should decide when to "take" a new version. There are lot of ways to manage that -- versioned endpoints, e.g., so that dependents can take the new when they are ready. But it's extra complexity that's tricky in practice. e.g., you really ought to semver the endpoints, and keep versions as long as there could be any dependents... but how many is that, and how do you know? From what I've seen, people don't do that and instead dependencies push new versions, ready or not, and just deal with the problems as breakages in production, which is pretty terrible.)

by jmull 3y ago

leeoniya 3y ago

i think doing releases, deployments, and rollbacks is trickier in a monorepo. with multiple services/repos, each team can handle their own release cycles, on-call rotation, and only deal with the bits, tests, and failures they wrote. you lose some CPU/RAM/IO efficiency, but you gain autonomy and resilience, and faster time to resolution. https://blog.nelhage.com/post/efficiency-vs-resiliency/ https://blog.nelhage.com/post/efficiency-vs-resiliency/ e.g. at Grafana we're working through some of these decoupling-to-microservices challenges, because the SREs that deploy to our infra should not need to deal with investigating and rolling back a whole monolith due to some regression introduced by some specific team to a core datasource plugin, or frontend plugin/panel. the pain at scale is very real, and engineering hours are by far more expensive than the small efficiency loss you get by over-provisioning the metal a bit.

jmull 3y ago
I didn't mean to say there are no reasons to have separate repos, just more responding to the post above mine. But I will note that almost all the benefits listed aren't specific to micro services. (Also, to me, it's flawed that a dependency can really push to production without coordination. At the least, dependent components should decide when to "take" a new version. There are lot of ways to manage that -- versioned endpoints, e.g., so that dependents can take the new when they are ready. But it's extra complexity that's tricky in practice. e.g., you really ought to semver the endpoints, and keep versions as long as there could be any dependents... but how many is that, and how do you know? From what I've seen, people don't do that and instead dependencies push new versions, ready or not, and just deal with the problems as breakages in production, which is pretty terrible.)