4 ms·

Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.

by abirch 1y ago

xingped 1y ago
The best use case is promotion! Welcome to big tech, where all the teams get reshuffled every few months and every microservice exists because some dev needed a promotion. The greater the ratio of microservices to devs, the better your manager looks! (Dev work-life balance be damned, we pay you to ruin your life.)
steveBK123 1y ago
Every org I've tried to see push microservices did exactly the wrong version. Rather than 1 micro service per team, which many devs.. it was some team that owns 20 services, generally way more services than developers. It's probably just how non-lean Mag7 were in peak vs how lean most other orgs that try to ape them are.
- jamesfinlayson 1y ago
  Yep, I remember working at a place where one team churned out a large majority of the microservices and the other three teams just kept on doing their thing. The microservice team were especially terrible because the did all the initial work and basked in the "glory", but when it came to maintaining the services, they wanted nothing to do with it.
  - steveBK123 1y ago
    At some point it just doesn't scale for the team that owns all the micro services. It's poor organizational decision making to have this setup. Sure a monolith that does 1000 things might not be ideal, but 100 repos for 100 micro services owned by a team of 5-10 devs is unmanageable on the other end of the spectrum. Oh and everyone forgets the orchestration layer.
eloisant 1y ago
1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case. You can have a distributed system of multiple services of a decent size. I know "services of a decent size" isn't as catchy as "go for one huge monolith!" or "microservices!" but that's the sensible way to approach things.
- monero-xmr 1y ago
  We solve the problem of 50 devs working in a single monolith with folder and file structure, separation of concerns, basic stuff like this
  - mjr00 1y ago
    Folder and file structure and separation of concerns doesn't change the fact that if you have one deployable artifact, it's all sharing the same runtime when deployed. Which means the underlying versions of Java/Go/Python/etc, or core shared libraries, all need to be updated at the same time. All the code is far more coupled than it first seems.
    - monero-xmr 1y ago
      All of that is so much easier with a single monorepo
      - mjr00 1y ago
        Monorepo is orthogonal to services though. You can have a monorepo with multiple services in it. Even with a monorepo, you will hit a point where you have 1, 10, 100 million lines of e.g. Python, realize you should upgrade from 3.8 to 3.14 because it's EOL, and feel a lot of pain as you have to do a big-bang, all-at-once change, fixing every single breaking change, including from libraries which you also have to update. There's no way around this in current mainstream languages.
roguecoder 1y ago
I mean, "GREAT" until you need to do any kind of refactoring, or the company grows, or shrinks, or reorgs, or you have a feature that needs to change more than one service. The "one team per microservice" makes code-enclosure style code ownership possible, but it is the least efficient way I have ever seen software written. I've long wanted to hack an IDE so people are only allowed to change the Java objects they created, and then put six Java programmers in a room and make them write an application, yelling back and forth across the room. "CAN YOU ADD A VERSION OF THAT METHOD THAT ACCEPTS THIS NEW CLASS?" "SURE THING! TRY THAT?" People discount the costs of microservices because they makes management's job easier, especially when companies have adopted global promotion processes. But unless they are solving a real technical constriant, they are a shitty way to work as an engineer.
__MatrixMan__ 1y ago
As long as that team built those microservices to solve whatever problem they're responsible for solving I think it's better to let the problem domain dictate how many you need. Better to have seams that make sense in terms of the surrounding code than to have them in arbitrary places based on the org chart. The trouble comes when some political wind blows and reshuffles the org chart, and now you're responsible for some services that only made sense in the context of a political reality that no longer exists.
dec0dedab0de 1y ago
I generally agree, but there are some decent use cases for one team to have multiple services micro or otherwise: 1. when the requirements are better served by a different language/location/environment/platform.. or by deploying a 3rd party app. 2. some of the services need to quickly scale up and down, and you have enough traffic for it to be worth it. 3. if you have a tight SLA for parts of the app but not all of it.
antonvs 1y ago
I’m guessing you’re thinking of a certain kind of application (web apps perhaps?), where a monolith can make sense. But that’s but the only kind of application. We have dozens of service components that are all largely independent of each other - combining them together would be purely a packaging decision, and wouldn’t really simplify much. In some cases, it wouldn’t make sense or even be possible at all. An example is our execution agent, which executes customer workflows - that’s completely independent both conceptually and from a security perspective. Each agent instance executes a single flow at a time, for resource consumption and security reasons, which entails an ecosystem of services to manage that - messaging, data ingestion at scale (100K flows per day, multi-petabyte “hot” datastore for active data), orchestration, and other supporting services such as data access and network routing. All of our teams support multiple services, and many of them qualify as microservices.

Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.

by abirch 1y ago

Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.

xingped 1y ago

The best use case is promotion! Welcome to big tech, where all the teams get reshuffled every few months and every microservice exists because some dev needed a promotion. The greater the ratio of microservices to devs, the better your manager looks! (Dev work-life balance be damned, we pay you to ruin your life.)

steveBK123 1y ago

Every org I've tried to see push microservices did exactly the wrong version. Rather than 1 micro service per team, which many devs.. it was some team that owns 20 services, generally way more services than developers. It's probably just how non-lean Mag7 were in peak vs how lean most other orgs that try to ape them are.

jamesfinlayson 1y ago
Yep, I remember working at a place where one team churned out a large majority of the microservices and the other three teams just kept on doing their thing. The microservice team were especially terrible because the did all the initial work and basked in the "glory", but when it came to maintaining the services, they wanted nothing to do with it.
- steveBK123 1y ago
  At some point it just doesn't scale for the team that owns all the micro services. It's poor organizational decision making to have this setup. Sure a monolith that does 1000 things might not be ideal, but 100 repos for 100 micro services owned by a team of 5-10 devs is unmanageable on the other end of the spectrum. Oh and everyone forgets the orchestration layer.

eloisant 1y ago

1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case. You can have a distributed system of multiple services of a decent size. I know "services of a decent size" isn't as catchy as "go for one huge monolith!" or "microservices!" but that's the sensible way to approach things.

monero-xmr 1y ago
We solve the problem of 50 devs working in a single monolith with folder and file structure, separation of concerns, basic stuff like this
- mjr00 1y ago
  Folder and file structure and separation of concerns doesn't change the fact that if you have one deployable artifact, it's all sharing the same runtime when deployed. Which means the underlying versions of Java/Go/Python/etc, or core shared libraries, all need to be updated at the same time. All the code is far more coupled than it first seems.
  - monero-xmr 1y ago
    All of that is so much easier with a single monorepo
    - mjr00 1y ago
      Monorepo is orthogonal to services though. You can have a monorepo with multiple services in it. Even with a monorepo, you will hit a point where you have 1, 10, 100 million lines of e.g. Python, realize you should upgrade from 3.8 to 3.14 because it's EOL, and feel a lot of pain as you have to do a big-bang, all-at-once change, fixing every single breaking change, including from libraries which you also have to update. There's no way around this in current mainstream languages.

roguecoder 1y ago

I mean, "GREAT" until you need to do any kind of refactoring, or the company grows, or shrinks, or reorgs, or you have a feature that needs to change more than one service. The "one team per microservice" makes code-enclosure style code ownership possible, but it is the least efficient way I have ever seen software written. I've long wanted to hack an IDE so people are only allowed to change the Java objects they created, and then put six Java programmers in a room and make them write an application, yelling back and forth across the room. "CAN YOU ADD A VERSION OF THAT METHOD THAT ACCEPTS THIS NEW CLASS?" "SURE THING! TRY THAT?" People discount the costs of microservices because they makes management's job easier, especially when companies have adopted global promotion processes. But unless they are solving a real technical constriant, they are a shitty way to work as an engineer.

__MatrixMan__ 1y ago

As long as that team built those microservices to solve whatever problem they're responsible for solving I think it's better to let the problem domain dictate how many you need. Better to have seams that make sense in terms of the surrounding code than to have them in arbitrary places based on the org chart. The trouble comes when some political wind blows and reshuffles the org chart, and now you're responsible for some services that only made sense in the context of a political reality that no longer exists.

dec0dedab0de 1y ago

I generally agree, but there are some decent use cases for one team to have multiple services micro or otherwise: 1. when the requirements are better served by a different language/location/environment/platform.. or by deploying a 3rd party app. 2. some of the services need to quickly scale up and down, and you have enough traffic for it to be worth it. 3. if you have a tight SLA for parts of the app but not all of it.

antonvs 1y ago

I’m guessing you’re thinking of a certain kind of application (web apps perhaps?), where a monolith can make sense. But that’s but the only kind of application. We have dozens of service components that are all largely independent of each other - combining them together would be purely a packaging decision, and wouldn’t really simplify much. In some cases, it wouldn’t make sense or even be possible at all. An example is our execution agent, which executes customer workflows - that’s completely independent both conceptually and from a security perspective. Each agent instance executes a single flow at a time, for resource consumption and security reasons, which entails an ecosystem of services to manage that - messaging, data ingestion at scale (100K flows per day, multi-petabyte “hot” datastore for active data), orchestration, and other supporting services such as data access and network routing. All of our teams support multiple services, and many of them qualify as microservices.