Hacker News new | ask | show | jobs
by recursivedoubts 1661 days ago
Microservices means just that: tiny, single purpose services that deploy and scale on their own.

I often see appeals to Conway's Law when discussing microservices, but teams don't organize themselves this way. Instead, teams work on a macro services: the email delivery team, or the monitoring team, or whatever. In most cases these macroservices would be best implemented and deployed as a monolith, and then presented to the outside world over a reasonable API.

1 comments

^ This. Microservices are introduced because it seems like they'll be able to decouple and scale well, and then they make mistakes that make everything even harder than if it'd stayed a monolith.

Usually they don't plan for how they'll coordinate their work, and that leaves gaps in the design, and puts more risk on the business.

  Team A:
       ↑                    Email product:
     __|_____________        ↑          Service C <----------
    / How do we      \       |          Service D <--        \
    | work together   |    ---------------------     \  ------\--------------
    | on overall      |   | How do we manage    |    | | How do we           |
    | system design?  |   | stakeholder risk?   |    | | coordinate changes? |
     \_______________/     ---------------------     | \--------/----------- /
       |                      |                      |          |
       ↓                      |                       \         |
  Team B:                     ↓                        |        |
                            "Data" team:               |       /
                                         Service A <---|-------
                                         Service B <--/

On top of that, they don't even make a true microservice. They start directly calling into each others' data rather than interface at an API layer, they make assumptions about how each other works, they don't do load testing or set limits or quotas... and because none of them understand the rest of the system, they don't see that their mutual lack of understanding is the cause of their problems.

Even with multiple teams, if they're forced to work inside a monolith, there's a much better chance they will by accident come to understand the rest of the system.

Total tangent: very nice ASCII diagram, especially for a throwaway account. It's so unusually nice that it'd probably help identify the author if they ever made ASCII diagrams on their non-throwaway account (and who could resist?).