3 ms·

The architecture is the function of number of people in the system. How do you manage 100 people in a monolith? 250? What if one group gets to a broken state bu

The architecture is the function of number of people in the system. How do you manage 100 people in a monolith? 250? What if one group gets to a broken state but another group needs to release to escape a broken state? Architecture is often solving a human problem. That said, too many teams break out way too early.

lucianbr 2y ago
Often the way they attepmt to manage 100 people is to split the monolith into a distributed monolith. Now you have all the same problems plus some new ones, but hey, we're "managing" the human problem. And considering they somehow muddle along, with one person sometimes breaking everything for the other 99, and all the other problems, I think they could very well muddle along with a monolith. With 100 or however many programmers. Yes, the distributed system with well thought out splits into services would be an improvement. But it's clearly not a necessity. So it remains that some places at least, use it out of some other reason - fad, cargo culting, whatever. Architecture should be solving the human or other problems, definitely. But how often it does... I guess each with their own experience.
davedx 2y ago
I’ve heard this and at some large engineering orgs, I’ve even occasionally seen it applied sensibly, but IME irrational hype driven architecture dominates: 15 microservices at companies with 5 engineers. Event sourcing where it made no sense. Apache Spark used on a project where all the data and processing fit on a laptop. Orchestration layers; frontends for backends; queues everywhere; the list is endless.
- ebiester 2y ago
  We agree there. Many teams went way too far in the other direction. There is a happy medium of one service per 1-3 teams with a few dedicated outliers such as third party connectors, and using libraries judiciously within larger codebases.
jiggawatts 2y ago
Just today I had to explain to a two-man team that using five Git repos and four different PaaS products for what is basically a single web control — not a whole site — is a bit nuts They mumbled something about “architecture” before returning to tinker on their Rube Goldberg machine… which is four months late and missing half the required features. There just isn’t any common sense in engineering and everyone applauds monstrously complex solutions. The one lone wolf suggesting “maaaaybe this just needs to be a single project in a single repo deploying to a vanilla web site” gets suspicious looks from managers that have already approved the project opex budget.
dventimi 2y ago
"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.

lucianbr 2y ago

Often the way they attepmt to manage 100 people is to split the monolith into a distributed monolith. Now you have all the same problems plus some new ones, but hey, we're "managing" the human problem. And considering they somehow muddle along, with one person sometimes breaking everything for the other 99, and all the other problems, I think they could very well muddle along with a monolith. With 100 or however many programmers. Yes, the distributed system with well thought out splits into services would be an improvement. But it's clearly not a necessity. So it remains that some places at least, use it out of some other reason - fad, cargo culting, whatever. Architecture should be solving the human or other problems, definitely. But how often it does... I guess each with their own experience.

davedx 2y ago

I’ve heard this and at some large engineering orgs, I’ve even occasionally seen it applied sensibly, but IME irrational hype driven architecture dominates: 15 microservices at companies with 5 engineers. Event sourcing where it made no sense. Apache Spark used on a project where all the data and processing fit on a laptop. Orchestration layers; frontends for backends; queues everywhere; the list is endless.

ebiester 2y ago
We agree there. Many teams went way too far in the other direction. There is a happy medium of one service per 1-3 teams with a few dedicated outliers such as third party connectors, and using libraries judiciously within larger codebases.

jiggawatts 2y ago

Just today I had to explain to a two-man team that using five Git repos and four different PaaS products for what is basically a single web control — not a whole site — is a bit nuts They mumbled something about “architecture” before returning to tinker on their Rube Goldberg machine… which is four months late and missing half the required features. There just isn’t any common sense in engineering and everyone applauds monstrously complex solutions. The one lone wolf suggesting “maaaaybe this just needs to be a single project in a single repo deploying to a vanilla web site” gets suspicious looks from managers that have already approved the project opex budget.

dventimi 2y ago

"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.