5 ms·

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services

I think the first step toward sanity is to stop factoring services by team sizes - “we have 100 people so require 20 microservices”. Instead, factor services along natural fault lines. These are areas in the solution that scale differently from other parts and can tolerate communicating over http or message queue. It is fine to have lots of people work on a single service. We compose things using 3rd party libraries all the time. Just treat internal code a bit more like 3rd party libraries.

kqr 4y ago
Could you elaborate on what you mean by "natural fault lines"? The rest of that paragraph seems to refer to performance -- is that the criterion? Do the natural fault lines shift if you manage to optimise the performance of a component, so that it starts scaling at the same rates as its neighbours?
- osigurdson 4y ago
  It is hard to say without understanding the system. In my own case it is auth, output (1D,2D,3D), logging and sim but that is meaningless outside of my application's context.
dasil003 4y ago
You're right that factoring into services should be based on natural domain boundaries. That said, it feels like a bit of a strawman to suggest that people are driving their architecture with naive math like this. I've definitely seen journeyman engineers coming out of FAANG and other big companies proposing overly complex service topographies, but there is always at least a veneer of semantic justification. That's not to say there's no relationship between team size and the applicability of a service-oriented architecture. Microservices are a way of drawing hard boundaries around blocks of logic. These boundaries come with cognitive and operational costs, so they represent significant overhead, but they are a tool for abstracting both logic and physical operations to the maximum degree possible (100% is never possible for a single application). In order to get a net benefit, you have to have enough engineers that they can be experts in a subset of services, and the interfaces to their peer services have to be reliable and stable enough that they can be productive without knowing anything about their internals. So while I agree with you there is no universal floor of microservices that makes based purely on team size, there definitely is a ceiling.
- osigurdson 4y ago
  >> there definitely is a ceiling Is there though? Operating systems have 10K - 20K devs based on a casual internet search. Of course there are many services / processes but they are not communicating using an http API or message queue. Similarly, Postgres has 350 people. I don't think team size is a factor at all.
  - dasil003 4y ago
    I was thinking of common server-based applications serving millions of clients. Obviously lower-level applications that must run on a single box need different techniques to encapsulate logic and enable scaling of their teams.
    - osigurdson 4y ago
      Agree. However, this seems to be pointing back to the problem again, not team size.
rqtwteye 4y ago
“we have 100 people so require 20 microservices”. More like 3 people requiring 13 microservices
- Spivak 4y ago
  I'm convinced that micro-service hell happens when the primary app calcifies and becomes too difficult to modify.
  - kqr 4y ago
    What are the specific decisions along this course of events? I guess nobody says "Our primary app has calcified and become too difficult to modify. Let's make microservice hell!" But what do people say that leads down that road, in your experience?
    - justinclift 4y ago
      Pretty sure this would be fairly common: Welcome to your new job as Architect for our software! What are some of the main bullet points you have in mind for our next major release... ?
  - rqtwteye 4y ago
    Micro service hell happens with new apps that are designed from scratch.
  - deleted 4y ago
    [deleted]
  - osigurdson 4y ago
    Micro-services are currently on trend so hard to argue with unless you are a founder. Maybe the best thing to do for the industry in general is go absolutely nuts with microservices. Factor projects so every method is a separate service / lambda. If anyone complains, use the single responsibility principal to snuff out all opposition. Once we've explored this to its logical conclusion the pendulum will swing back to something more logical. Of course, it will swing too far and the cool kids will only want to work on monoliths even when it doesn't make sense (kind of like what is happening now with SQL maximalism).
viraptor 4y ago
> "we have 100 people so require 20 microservices" Is this something that actually happened? Not heard from some third party - actually has someone experienced this as a decision in a technical team? It seems... unlikely.
- kqr 4y ago
  This is an application of Conway's law. If we want small five-person teams then there are 20 teams and it makes sense to simplify communication by decomposing the system into 20 parts. (Not saying it's the right way to do things, just the natural way to optimise if you need to keep 20 teams busy working on one system. I think the incorrect assumption is that all 20 teams need to be busy doing the same thing.)
  - osigurdson 4y ago
    Decomposing the system into libraries is just as effective from this perspective as decomposing into services however. The thing that a typical http API gives you is stability (documentation, versioning and a deprecation policy). This can be done with a library as well. We know this works as 3rd party libraries work well and no communication with the authors of the library is needed. This is why I suggest team size is not a valid reason to break a problem into microservices. The problem itself is the thing to analyze.
- benjiweber 4y ago
  It's usually a consequence of something like Bezos' API mandate https://api-university.com/blog/the-api-mandate/ https://api-university.com/blog/the-api-mandate/ Multi-team ownership of a single deployable has downsides to tradeoff against the complexity of more service and harder boundaries.
  - viraptor 4y ago
    That doesn't translate from the mandate, which is what I'm trying to cautiously call out. There's a big difference between "our company will not have a god database" and "we need to make more services just because we have more people". The link also mentions that the mandate was "something long these lines" - we don't know exactly what the split rules were. I think people bring up an exaggerated idea of extreme microservices being forced on people when it rarely if ever happens. If not, I'm happy to hear actual first hand experiences.

kqr 4y ago

Could you elaborate on what you mean by "natural fault lines"? The rest of that paragraph seems to refer to performance -- is that the criterion? Do the natural fault lines shift if you manage to optimise the performance of a component, so that it starts scaling at the same rates as its neighbours?

osigurdson 4y ago
It is hard to say without understanding the system. In my own case it is auth, output (1D,2D,3D), logging and sim but that is meaningless outside of my application's context.

dasil003 4y ago

You're right that factoring into services should be based on natural domain boundaries. That said, it feels like a bit of a strawman to suggest that people are driving their architecture with naive math like this. I've definitely seen journeyman engineers coming out of FAANG and other big companies proposing overly complex service topographies, but there is always at least a veneer of semantic justification. That's not to say there's no relationship between team size and the applicability of a service-oriented architecture. Microservices are a way of drawing hard boundaries around blocks of logic. These boundaries come with cognitive and operational costs, so they represent significant overhead, but they are a tool for abstracting both logic and physical operations to the maximum degree possible (100% is never possible for a single application). In order to get a net benefit, you have to have enough engineers that they can be experts in a subset of services, and the interfaces to their peer services have to be reliable and stable enough that they can be productive without knowing anything about their internals. So while I agree with you there is no universal floor of microservices that makes based purely on team size, there definitely is a ceiling.

osigurdson 4y ago
>> there definitely is a ceiling Is there though? Operating systems have 10K - 20K devs based on a casual internet search. Of course there are many services / processes but they are not communicating using an http API or message queue. Similarly, Postgres has 350 people. I don't think team size is a factor at all.
- dasil003 4y ago
  I was thinking of common server-based applications serving millions of clients. Obviously lower-level applications that must run on a single box need different techniques to encapsulate logic and enable scaling of their teams.
  - osigurdson 4y ago
    Agree. However, this seems to be pointing back to the problem again, not team size.

rqtwteye 4y ago

“we have 100 people so require 20 microservices”. More like 3 people requiring 13 microservices

Spivak 4y ago
I'm convinced that micro-service hell happens when the primary app calcifies and becomes too difficult to modify.
- kqr 4y ago
  What are the specific decisions along this course of events? I guess nobody says "Our primary app has calcified and become too difficult to modify. Let's make microservice hell!" But what do people say that leads down that road, in your experience?
  - justinclift 4y ago
    Pretty sure this would be fairly common: Welcome to your new job as Architect for our software! What are some of the main bullet points you have in mind for our next major release... ?
- rqtwteye 4y ago
  Micro service hell happens with new apps that are designed from scratch.
- deleted 4y ago
  [deleted]
- osigurdson 4y ago
  Micro-services are currently on trend so hard to argue with unless you are a founder. Maybe the best thing to do for the industry in general is go absolutely nuts with microservices. Factor projects so every method is a separate service / lambda. If anyone complains, use the single responsibility principal to snuff out all opposition. Once we've explored this to its logical conclusion the pendulum will swing back to something more logical. Of course, it will swing too far and the cool kids will only want to work on monoliths even when it doesn't make sense (kind of like what is happening now with SQL maximalism).

viraptor 4y ago

> "we have 100 people so require 20 microservices" Is this something that actually happened? Not heard from some third party - actually has someone experienced this as a decision in a technical team? It seems... unlikely.

kqr 4y ago
This is an application of Conway's law. If we want small five-person teams then there are 20 teams and it makes sense to simplify communication by decomposing the system into 20 parts. (Not saying it's the right way to do things, just the natural way to optimise if you need to keep 20 teams busy working on one system. I think the incorrect assumption is that all 20 teams need to be busy doing the same thing.)
- osigurdson 4y ago
  Decomposing the system into libraries is just as effective from this perspective as decomposing into services however. The thing that a typical http API gives you is stability (documentation, versioning and a deprecation policy). This can be done with a library as well. We know this works as 3rd party libraries work well and no communication with the authors of the library is needed. This is why I suggest team size is not a valid reason to break a problem into microservices. The problem itself is the thing to analyze.
benjiweber 4y ago
It's usually a consequence of something like Bezos' API mandate https://api-university.com/blog/the-api-mandate/ https://api-university.com/blog/the-api-mandate/ Multi-team ownership of a single deployable has downsides to tradeoff against the complexity of more service and harder boundaries.
- viraptor 4y ago
  That doesn't translate from the mandate, which is what I'm trying to cautiously call out. There's a big difference between "our company will not have a god database" and "we need to make more services just because we have more people". The link also mentions that the mandate was "something long these lines" - we don't know exactly what the split rules were. I think people bring up an exaggerated idea of extreme microservices being forced on people when it rarely if ever happens. If not, I'm happy to hear actual first hand experiences.