3 ms·

"How do you manage 100 people in a monolith?" Assign the monolith to 5 of them then find something productive for the other 95 people to do.

ebiester 2y ago
Now, how do you explain to that executive that they will not get that feature in 3 months but rather in 5 years if the company survives that long with work screeching to a halt? You have turned 20 teams working on 20 different focuses into 1 team. The focuses are interconnected but 90% independent. One team is working on billing. Another team is working on admin. Another team is working on a feature that has blocked five deals this quarter totaling $800,000 dollars in potential contract. Another team is working on imports from other external systems. Another team is working on exports to CSV and Looker and other platforms. Yet another team is working on a feature that is only connected because they are the same user base but otherwise has no relation. Another team is directly tied to all of the same data, but could be flying on their own with a reasonable set of CRUD APIs. These all get mashed into the same codebase early on because everyone is going as fast as possible with 8 developers two funding rounds ago. I am not excusing systems that are a microservice to a developer, or worse, but these patterns evolved because there was a need.
- dventimi 2y ago
  Now, how do you explain to that executive that they will not get that feature in 3 months but rather in 5 years I have no idea, but I don't worry about it because I haven't been persuaded that will happen. You have turned 20 teams working on 20 different focuses into 1 team. The focuses are interconnected but 90% independent. I would explain that what was originally presented to me as a monolith was later explained to me to be something else: a family of interrelated services. Then I would say that's a different problem, invoke Conway's Law, and say that they can stay as 20 different teams. I would also say that doesn't necessarily mean 20 different network servers and 40 different tiers, which in my experience is how "micro-services" are typically envisioned. these patterns evolved because there was a need I'm also not persuaded there was a [single] need rather than a network of interrelated needs, just as I'm not persuaded anyone here (including me) has a complete understanding of what all those needs were.
  - ebiester 2y ago
    Note that I am usually on the other side of this argument, but mostly due to nuance. In my world, monoliths are usually interrelated services that are in the same codebase and have poor boundary protection because they were started with teams that were later split along arbitrary boundaries. However, it's poorly factored because everyone has been rushing for so long that splitting it out is a giant cluster headache, and nobody can quite figure out where the bounded context is because it truly is different for each team. So, nobody knows what all the needs are, because there's enough work for 100 people and 15 product managers, and only a handful of people in the organization have a mental model of the entire system because they were an early employee, engineer or otherwise. So, can we agree on these architectural principals, except in edge cases: 1. A team must be in control of its own destiny. Team A releases must be independent of team B releases, and any interconnected development must be independently releasable (by feature flags by one example, but other patterns exist.) Otherwise, you get into release management hell. 2. Any communication between teams must be done by an API. That can be an HTTP API. That can be a library. That can be a stored procedure. But there must be a documented interface such that changes between teams are made obvious. From there, I think there are options. You can have multiple teams that each contribute a library to a monolith that releases on every library change. You can have microservices. You can have WAR files in java. You can have a monorepo and each team has a directory. There are many options, some of which are distributed. However, without those two architectural principals all development comes to a halt after 30-40 developers come on board. Microservices are used often because nobody managed to write a good set of books and blogs about how to keep 100 to 1000 developers humming along without the tests taking 4 hours to run and needing release managers to control the chaos. I don't dispute there are other ways to work, but the microservices crowd did the work to document good working patterns that keep humans in mind. and it comes back to my original point: The architecture is the function of number of people in the system.
    - dventimi 2y ago
      "So, can we agree on these architectural principals, except in edge cases: 1. A team must be in control of its own destiny... 2. Any communication between teams must be done by... an interface such that changes between teams are made obvious." Sure. You'll get no argument from me on these points... "it comes back to my original point: The architecture is the function of number of people in the system." ...or on this one. I will grant that a division of code along the same lines as the division of labor is both sensible and inevitable. I will also grant that 100 or 250 or 2500 or more people are sometimes needed for a firm to achieve its objectives. Will you grant that sometimes, they aren't? That sometimes, the tail wags the dog and the staff and its culture determine the architecture rather than the reverse? That sometimes, adding more people to a slow project just makes it slower? I ask these questions because in my world, micro-services have typically been narrowly defined as network servers in Java, Python, or Rust, each interacting with a database (sometimes, the same database) through an ORM, and a rigid adherence to this orthodoxy has padded resource budgets both in terms of compute and people and has sapped performance both in terms of compute and people.

ebiester 2y ago

Now, how do you explain to that executive that they will not get that feature in 3 months but rather in 5 years if the company survives that long with work screeching to a halt? You have turned 20 teams working on 20 different focuses into 1 team. The focuses are interconnected but 90% independent. One team is working on billing. Another team is working on admin. Another team is working on a feature that has blocked five deals this quarter totaling $800,000 dollars in potential contract. Another team is working on imports from other external systems. Another team is working on exports to CSV and Looker and other platforms. Yet another team is working on a feature that is only connected because they are the same user base but otherwise has no relation. Another team is directly tied to all of the same data, but could be flying on their own with a reasonable set of CRUD APIs. These all get mashed into the same codebase early on because everyone is going as fast as possible with 8 developers two funding rounds ago. I am not excusing systems that are a microservice to a developer, or worse, but these patterns evolved because there was a need.

dventimi 2y ago
Now, how do you explain to that executive that they will not get that feature in 3 months but rather in 5 years I have no idea, but I don't worry about it because I haven't been persuaded that will happen. You have turned 20 teams working on 20 different focuses into 1 team. The focuses are interconnected but 90% independent. I would explain that what was originally presented to me as a monolith was later explained to me to be something else: a family of interrelated services. Then I would say that's a different problem, invoke Conway's Law, and say that they can stay as 20 different teams. I would also say that doesn't necessarily mean 20 different network servers and 40 different tiers, which in my experience is how "micro-services" are typically envisioned. these patterns evolved because there was a need I'm also not persuaded there was a [single] need rather than a network of interrelated needs, just as I'm not persuaded anyone here (including me) has a complete understanding of what all those needs were.
- ebiester 2y ago
  Note that I am usually on the other side of this argument, but mostly due to nuance. In my world, monoliths are usually interrelated services that are in the same codebase and have poor boundary protection because they were started with teams that were later split along arbitrary boundaries. However, it's poorly factored because everyone has been rushing for so long that splitting it out is a giant cluster headache, and nobody can quite figure out where the bounded context is because it truly is different for each team. So, nobody knows what all the needs are, because there's enough work for 100 people and 15 product managers, and only a handful of people in the organization have a mental model of the entire system because they were an early employee, engineer or otherwise. So, can we agree on these architectural principals, except in edge cases: 1. A team must be in control of its own destiny. Team A releases must be independent of team B releases, and any interconnected development must be independently releasable (by feature flags by one example, but other patterns exist.) Otherwise, you get into release management hell. 2. Any communication between teams must be done by an API. That can be an HTTP API. That can be a library. That can be a stored procedure. But there must be a documented interface such that changes between teams are made obvious. From there, I think there are options. You can have multiple teams that each contribute a library to a monolith that releases on every library change. You can have microservices. You can have WAR files in java. You can have a monorepo and each team has a directory. There are many options, some of which are distributed. However, without those two architectural principals all development comes to a halt after 30-40 developers come on board. Microservices are used often because nobody managed to write a good set of books and blogs about how to keep 100 to 1000 developers humming along without the tests taking 4 hours to run and needing release managers to control the chaos. I don't dispute there are other ways to work, but the microservices crowd did the work to document good working patterns that keep humans in mind. and it comes back to my original point: The architecture is the function of number of people in the system.
  - dventimi 2y ago
    "So, can we agree on these architectural principals, except in edge cases: 1. A team must be in control of its own destiny... 2. Any communication between teams must be done by... an interface such that changes between teams are made obvious." Sure. You'll get no argument from me on these points... "it comes back to my original point: The architecture is the function of number of people in the system." ...or on this one. I will grant that a division of code along the same lines as the division of labor is both sensible and inevitable. I will also grant that 100 or 250 or 2500 or more people are sometimes needed for a firm to achieve its objectives. Will you grant that sometimes, they aren't? That sometimes, the tail wags the dog and the staff and its culture determine the architecture rather than the reverse? That sometimes, adding more people to a slow project just makes it slower? I ask these questions because in my world, micro-services have typically been narrowly defined as network servers in Java, Python, or Rust, each interacting with a database (sometimes, the same database) through an ORM, and a rigid adherence to this orthodoxy has padded resource budgets both in terms of compute and people and has sapped performance both in terms of compute and people.