• Knusper@feddit.de
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    Yeah, it’s tricky. If a project is more complex than a single dev team can handle, then managers feel forced to makes decisions around complexity, because of that whole “software architecture resembles organization structure”.

    But they obviously don’t understand the whole complexity ahead of the project start, so making nuanced decisions is not possible. They’d have to arbitrarily pick an architecture sizing in between.
    And that makes it quite tempting to simply reach for the biggest hammer.

    • lysdexic@programming.devOPM
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      But they obviously don’t understand the whole complexity ahead of the project start, so making nuanced decisions is not possible. They’d have to arbitrarily pick an architecture sizing in between.

      The single most important decision is external interfaces, and establish service level agreements with clients.

      Once the external interface is set, managers have total control over what happens internally. If they choose to, they can repeatedly move back and forth peeling out and merging in microservices. That’s actually one of the main selling points of microservices: once an API gateway is in place, they are completely free to work independently on independent services and even their replacements.

      Microservices are first and foremost an organizational tool.

      • Knusper@feddit.de
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Hmm, not sure, I fully understand your point.
        Yes, having those API gateways in place gives you flexibility in organization, but they cost developer velocity and therefore also money.

        So, if you won’t need the flexibility of those API gateways, then you shouldn’t build/maintain them. But that is obviously easier said thsn predicted, which is why misjudgements happen…