6 ms·

> Splitting a system into subsystems allows each team to focus on their piece of the puzzle while minimizing the amount of peer-to-peer coordination. This does

> Splitting a system into subsystems allows each team to focus on their piece of the puzzle while minimizing the amount of peer-to-peer coordination. This does not happen at all. When you break a system into subsystems, all the previous connections that get remapped to new connections between subsystems still need to happen, in order to solve the fundamental problem that the system solves — except now instead of just making the connection directly, there has to be a "cross-functional" meeting between teams and a complicated communication layer between the systems. And if somehow you find a breakdown that requires minimal connections between subsystems, then those connections wouldn't have existed in the original system either, and the N² problem doesn't exist.

jedberg 3y ago
If that's the experience then you're doing services wrong. Each service should have its own datastore and a single API. The interface between services should be a single connection. There should be maybe one meeting where the caller defines what they need the service to return to them.
- 10000truths 3y ago
  The problem with this is that you have to be really damned careful how you split things up. If your separate data stores end up having to be joined together later on because some new business feature requires them to be cross-referenced, you're painted into one of two corners: 1. Merge the two services (and their data stores) into one and cause havoc downstream of either service 2. Burn through your network latency/throughput budget trying to reinvent a DB join across RPC boundaries (and god forbid if you can't batch multiple lookups in a single API call!)
  - dahwolf 3y ago
    Exactly. Software developers will never learn that the separation of concerns is a myth. In reality, UI, business logic and data are deeply entangled. Hence, moving these things apart makes everything worse.
- ris58h 3y ago
  > There should be maybe one meeting Oh sweet summer child
  - sethammons 3y ago
    I'm willing to bet you do not know who you replied to. Their resume is more impressive than most.
    - ris58h 3y ago
      https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority
      - RugnirViking 3y ago
        your "argument" was literally just telling the person that they were naive for thinking things could ever be handled by one meeting. turns out, they inarguably have a whole lot of experience at high levels in the biggest companies in the world. Either they're straight up lying, or it is in fact possible to resolve things with a single meeting. Why wouldn't that be the case?
        ris58h 3y ago
        I can tell you many other wisdoms: code should be tested, code shouldn't contain bugs, everything should be done before deadline, etc. The thing is in reality it's not that easy. > Either they're straight up lying, or it is in fact possible to resolve things with a single meeting. Something can be done in a single meeting but not everything. But you gave me only two alternatives without anything between so there is another useful link for you https://en.m.wikipedia.org/wiki/False_dilemma https://en.m.wikipedia.org/wiki/False_dilemma
        sethammons 3y ago
        oh sweet summer child; have you not heard of the fallacy fallacy? snark aside, just because a logical fallacy exists in an argument, it does not mean the argument is untrue. My experience echoes jedburg's - services should maintain their own datastore and provide api access. This allows them to be decoupled and allows the service to alter their datastore as needed. When multiple services leverage the same underlying datastore, things can get overly coupled. This becomes increasingly important as organizations grow because the coupling means more overhead communicating and aligning around changes. Jedburg is an expert because he has seen this happen in multiple companies. I have too, but I don't have the speaking/consulting breadth of experience that they have. Credentialing and appeals to authority work because we are squishy humans and we can't verify everything so we lean in on others. That does not mean that authorities are always right, but when their experience and advice mirrors other's experience and advice, there is something to it. And for the record, in public companies (two of them), I have exactly seen this play out: a well defined api that does not allow others to muddle in their datastore leading to _single_ meetings where new functionality is discussed and agreed upon and later implemented. I have also experienced the pain of multiple teams sharing a datastore when the datastore now needs to be altered which led to dozens of meetings across several teams and a rollout plan that was measured in months and quarters due to coordination needs. I can firmly say that the latter is a much harder (and expensive!) problem to solve in each case I've experienced.
threeseed 3y ago
> there has to be a "cross-functional" meeting between teams and a complicated communication layer between the systems Of all the things wrong with micro-services this isn't one of them. The "complicated" communication layer is always either REST/JSON or GRPC. Both of which are simple, easy to debug, proven and require nothing more than a simple discussion over an API contract.
- The_Colonel 3y ago
  > Of all the things wrong with micro-services this isn't one of them. It is, exacerbated by the over-use. > The "complicated" communication layer is always either REST/JSON or GRPC. Going over network, which is slower, unreliable, poorly typed. It's orders of magnitude more difficult to refactor a published REST API in comparison to e.g. Java interface within a monolith. Microservices are generally far from easy to debug. In the best case scenario you have the whole stack locally and can put breakpoints, add logging immediately. But that happens rarely, debug port is often blocked (security), you can't easily modify the code to add some diagnostics without a complex CI dance etc.
  - threeseed 3y ago
    Maybe you've only worked on small projects. But I've never worked on a monolith project that I could run entirely locally. And this idea that APIs are slow, unreliable and unable be to be strongly typed is nonsense. This is 2023. We have plenty of tooling and techniques to make this robust.
    - plugin-baby 3y ago
      > I've never worked on a monolith project that I could run entirely locally. What are some examples of monolith components that couldn’t be run locally? Im guessing third-party integrations, but perhaps there are other things.
      - threeseed 3y ago
        For a monolith it's having to run the entire platform locally to fix one bug. That includes databases, caching, auth, ML models, mock API endpoints etc all pre-populated with sample data then the actual application which for complex, JVM based ones can often fail to launch if there isn't enough memory to pre-allocate. Many systems I have worked on all of that would simply not fit on a 16GB MBP.
devoutsalsa 3y ago
It's all fun & games until product wants to add a feature that doesn't map cleanly to your micro servies architecture. Then you end up hard coding you services into a macrolith. Good times.

jedberg 3y ago

If that's the experience then you're doing services wrong. Each service should have its own datastore and a single API. The interface between services should be a single connection. There should be maybe one meeting where the caller defines what they need the service to return to them.

10000truths 3y ago
The problem with this is that you have to be really damned careful how you split things up. If your separate data stores end up having to be joined together later on because some new business feature requires them to be cross-referenced, you're painted into one of two corners: 1. Merge the two services (and their data stores) into one and cause havoc downstream of either service 2. Burn through your network latency/throughput budget trying to reinvent a DB join across RPC boundaries (and god forbid if you can't batch multiple lookups in a single API call!)
- dahwolf 3y ago
  Exactly. Software developers will never learn that the separation of concerns is a myth. In reality, UI, business logic and data are deeply entangled. Hence, moving these things apart makes everything worse.
ris58h 3y ago
> There should be maybe one meeting Oh sweet summer child
- sethammons 3y ago
  I'm willing to bet you do not know who you replied to. Their resume is more impressive than most.
  - ris58h 3y ago
    https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority
    - RugnirViking 3y ago
      your "argument" was literally just telling the person that they were naive for thinking things could ever be handled by one meeting. turns out, they inarguably have a whole lot of experience at high levels in the biggest companies in the world. Either they're straight up lying, or it is in fact possible to resolve things with a single meeting. Why wouldn't that be the case?
      - ris58h 3y ago
        I can tell you many other wisdoms: code should be tested, code shouldn't contain bugs, everything should be done before deadline, etc. The thing is in reality it's not that easy. > Either they're straight up lying, or it is in fact possible to resolve things with a single meeting. Something can be done in a single meeting but not everything. But you gave me only two alternatives without anything between so there is another useful link for you https://en.m.wikipedia.org/wiki/False_dilemma https://en.m.wikipedia.org/wiki/False_dilemma
        sethammons 3y ago
        oh sweet summer child; have you not heard of the fallacy fallacy? snark aside, just because a logical fallacy exists in an argument, it does not mean the argument is untrue. My experience echoes jedburg's - services should maintain their own datastore and provide api access. This allows them to be decoupled and allows the service to alter their datastore as needed. When multiple services leverage the same underlying datastore, things can get overly coupled. This becomes increasingly important as organizations grow because the coupling means more overhead communicating and aligning around changes. Jedburg is an expert because he has seen this happen in multiple companies. I have too, but I don't have the speaking/consulting breadth of experience that they have. Credentialing and appeals to authority work because we are squishy humans and we can't verify everything so we lean in on others. That does not mean that authorities are always right, but when their experience and advice mirrors other's experience and advice, there is something to it. And for the record, in public companies (two of them), I have exactly seen this play out: a well defined api that does not allow others to muddle in their datastore leading to _single_ meetings where new functionality is discussed and agreed upon and later implemented. I have also experienced the pain of multiple teams sharing a datastore when the datastore now needs to be altered which led to dozens of meetings across several teams and a rollout plan that was measured in months and quarters due to coordination needs. I can firmly say that the latter is a much harder (and expensive!) problem to solve in each case I've experienced.

threeseed 3y ago

> there has to be a "cross-functional" meeting between teams and a complicated communication layer between the systems Of all the things wrong with micro-services this isn't one of them. The "complicated" communication layer is always either REST/JSON or GRPC. Both of which are simple, easy to debug, proven and require nothing more than a simple discussion over an API contract.

The_Colonel 3y ago
> Of all the things wrong with micro-services this isn't one of them. It is, exacerbated by the over-use. > The "complicated" communication layer is always either REST/JSON or GRPC. Going over network, which is slower, unreliable, poorly typed. It's orders of magnitude more difficult to refactor a published REST API in comparison to e.g. Java interface within a monolith. Microservices are generally far from easy to debug. In the best case scenario you have the whole stack locally and can put breakpoints, add logging immediately. But that happens rarely, debug port is often blocked (security), you can't easily modify the code to add some diagnostics without a complex CI dance etc.
- threeseed 3y ago
  Maybe you've only worked on small projects. But I've never worked on a monolith project that I could run entirely locally. And this idea that APIs are slow, unreliable and unable be to be strongly typed is nonsense. This is 2023. We have plenty of tooling and techniques to make this robust.
  - plugin-baby 3y ago
    > I've never worked on a monolith project that I could run entirely locally. What are some examples of monolith components that couldn’t be run locally? Im guessing third-party integrations, but perhaps there are other things.
    - threeseed 3y ago
      For a monolith it's having to run the entire platform locally to fix one bug. That includes databases, caching, auth, ML models, mock API endpoints etc all pre-populated with sample data then the actual application which for complex, JVM based ones can often fail to launch if there isn't enough memory to pre-allocate. Many systems I have worked on all of that would simply not fit on a 16GB MBP.

devoutsalsa 3y ago

It's all fun & games until product wants to add a feature that doesn't map cleanly to your micro servies architecture. Then you end up hard coding you services into a macrolith. Good times.