3 ms·

> The reason why microservices work so well is it provides a well-defined API entry point into a module. The caller ... can ignore the messy details of how that

> The reason why microservices work so well is it provides a well-defined API entry point into a module. The caller ... can ignore the messy details of how that API is implemented Honestly, everyone just re-interprets microservices as whatever they feel like! This particular quote is just describing modularity and encapsulation, something that Parnas could have told them in the '70s.[1] Microservices are about decoupling teams from each other so they can work and deploy on their own schedule. To a lesser extent, they're about scaling different parts of the system independently (on stacks that don't natively support that with a sane concurrency model). That's really just it. Everything else is hype and buzzwords. [1] https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/ https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-us...

vbezhenar 7y ago
Why can't you decouple teams form each other with modularity and encapsulation? I never worked in a team, but I could imagine that teams just have some agreements about interfaces and then work independently on a single code base but in a different classes and packages.
- yawaramin 7y ago
  Because modules in the same codebase have an unfortunate tendency to cross each others' boundaries. It's just too easy for them to reach into each others' implementation classes and couple together strongly. But if they're different codebases, there's a stronger wall between them.
  - mkleczek 7y ago
    (Micro)services and separate codebases are orthogonal. You can have multiple separate components (libraries) implemented in different codebases and linked as a single executable (which is actually really common). You can have (micro)services deployed from as single huge codebase - just take a look at all so-called monorepos.

vbezhenar 7y ago

Why can't you decouple teams form each other with modularity and encapsulation? I never worked in a team, but I could imagine that teams just have some agreements about interfaces and then work independently on a single code base but in a different classes and packages.

yawaramin 7y ago
Because modules in the same codebase have an unfortunate tendency to cross each others' boundaries. It's just too easy for them to reach into each others' implementation classes and couple together strongly. But if they're different codebases, there's a stronger wall between them.
- mkleczek 7y ago
  (Micro)services and separate codebases are orthogonal. You can have multiple separate components (libraries) implemented in different codebases and linked as a single executable (which is actually really common). You can have (micro)services deployed from as single huge codebase - just take a look at all so-called monorepos.