3 ms·

None of this addresses my question—what benefits do you get from having monorepo-with-microservices over a monolithic backend? All of the things you mentioned w

None of this addresses my question—what benefits do you get from having monorepo-with-microservices over a monolithic backend? All of the things you mentioned would be even easier with a monolithic backend.

staticassertion 5y ago
They solve different problems, some of which may overlap I suppose. For one thing you get clear ownership of deployed code. There isn't one monolithic service that everyone is responsible for babying, every team can baby their own, even if they all share libraries and whatnot. You also get things like fault isolation and fine grained scaling too.
echelon 5y ago
At scale, you almost never want a monolith. - Monoliths force you to coordinate deploys, which can be a pain. It's difficult to verify your changes in concert with others. - Bugs from one team can cause a rollback for everyone. - One N+1 query, nonlinear algorithm, or GC-contentious endpoint can send the entire system into a spiral and cause non-linear behavior. - You don't need to scale everything the same (services, databases, etc.) Your authentication pieces need massive scale: 10,000 QPS in an active-active configuration. Your random endpoint for the "XYZ promotion" does 0.5 QPM. - Engineers that build platforms can operate in Java/Go/Rust, engineers that build product can build in Ruby/Python/Node. - Payment data growing faster than user data? Scale your payment pieces. Shard their databases. They're safely cordoned off and isolated from anything else. The payments team(s) can focus on this one really hard problem without anyone else knowing or caring at all. - Engineers can have privileged access to the resources their team consumes and needs. You don't want your customer loyalty team having access to payment team data. Or your appointments team having access to user accounts and authentication. - You can hire for teams/concerns, and you have an interesting metric: number of services per engineer or team. It's actually pretty useful. - Mistakes in one corner can sometimes be completely isolated and not take down the entire company. This isn't always the case. Critical infra (auth, service discovery, networking) can take everything out. But your appointments or customer success app won't have any impact to the other business areas. Also, it's great to have those super mission-critical folks focused on only the extremely important function they serve. - Tech debt can live "under the covers". External teams calling your services might not know about the mess or the ongoing migrations under the hood. They don't need to know. (Granted, if your data model at scale sucks, this doesn't really afford much. But it is an easier puzzle to decompose.) tl;dr - teams are focused on things they own, scope is controlled, blast radius is limited, pieces scale independently as needed.

staticassertion 5y ago

They solve different problems, some of which may overlap I suppose. For one thing you get clear ownership of deployed code. There isn't one monolithic service that everyone is responsible for babying, every team can baby their own, even if they all share libraries and whatnot. You also get things like fault isolation and fine grained scaling too.

echelon 5y ago

At scale, you almost never want a monolith. - Monoliths force you to coordinate deploys, which can be a pain. It's difficult to verify your changes in concert with others. - Bugs from one team can cause a rollback for everyone. - One N+1 query, nonlinear algorithm, or GC-contentious endpoint can send the entire system into a spiral and cause non-linear behavior. - You don't need to scale everything the same (services, databases, etc.) Your authentication pieces need massive scale: 10,000 QPS in an active-active configuration. Your random endpoint for the "XYZ promotion" does 0.5 QPM. - Engineers that build platforms can operate in Java/Go/Rust, engineers that build product can build in Ruby/Python/Node. - Payment data growing faster than user data? Scale your payment pieces. Shard their databases. They're safely cordoned off and isolated from anything else. The payments team(s) can focus on this one really hard problem without anyone else knowing or caring at all. - Engineers can have privileged access to the resources their team consumes and needs. You don't want your customer loyalty team having access to payment team data. Or your appointments team having access to user accounts and authentication. - You can hire for teams/concerns, and you have an interesting metric: number of services per engineer or team. It's actually pretty useful. - Mistakes in one corner can sometimes be completely isolated and not take down the entire company. This isn't always the case. Critical infra (auth, service discovery, networking) can take everything out. But your appointments or customer success app won't have any impact to the other business areas. Also, it's great to have those super mission-critical folks focused on only the extremely important function they serve. - Tech debt can live "under the covers". External teams calling your services might not know about the mess or the ongoing migrations under the hood. They don't need to know. (Granted, if your data model at scale sucks, this doesn't really afford much. But it is an easier puzzle to decompose.) tl;dr - teams are focused on things they own, scope is controlled, blast radius is limited, pieces scale independently as needed.