• Renacles@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      1 year ago

      It’s not so bad, microservices let’s you focus on your current task instead of having to deal with years upon years of legacy code every day.

      Microservices can get messy but they are much better than the alternative even if you aren’t looking at performance and scalability.

  • tyw0kki@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 year ago

    Trying to do Postgresql TLS /w Internal PKI chain created by Cert-Manager made me want to throw my laptop out the window yesterday.

    This stuff is hard.

  • derpgon@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    It’s always the full circle - from monolith, to micro services, then someone just copies the code back to the main repo, and we’re back to square one.

  • marcos@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    We are at layer 5 at work, blissfully ignoring anything deeper. What is quite the thing because microservices don’t become very useful until you reach layer 6.

    But well, I stopped advocating for consolidating most of the services a couple of years ago. AFAIK, we need some 3 large services and everything else should be a monolith.

    • stevecrox@kbin.social
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      The big argument for mono repos is checking out multiple repositories is “hard” while checking out one repository is “easy” but…

      Service Oriented Architecture became a thing because monolithic code bases were often becoming spaghetti. I worked on a project where removing an option from a preference window (max map zoom), broke a message table (because the number of visible rows in a table (not its size in the UI) was linked to the max zoom you supplied to a map library, for no reason).

      Thus the idea you should wrap everything you do as a self contained service, with a known interface. The idea being you could write an entirely new implementation of a service, implement the interface and everything would work. Microservices are a continuation of this idea.

      Yet every node/python based mono repo I have seen will have python files directly imported filed from inside anouther component/service. Not simply common aretfacts but all sorts of random parts. Subverting the concept of micro service (and recreating the problem).

      Separate repositories block this because each repository will be built in isolation on a CI, flagging the link. This forces you to release each repository and pull things in as a dependency. Which encourages you to design code to support that.

      A common monorepo problem is to shove everything in a docker image and call it a day. Then if you need a class from one monorepo in anouther one, you don’t have an artefacts so lazy devs just copy/paste files between monorepos.

      Monorepos aren’t bad practice by themselves, they encourage bad practice. Separate repositories encourage good practice (literally the need to manage them separately drives it).