• Renacles@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    Micro services are a lot easier to scale out since they behave independently from each other, you can have different levels of replication and concurrency based on the traffic that each part of your system receives.

    Something that I think is pretty huge is that, done right, you end up with a bunch of smaller databases, meaning you can save a lot of money by having different levels of security and replication depending on how sensitive the data is.

    This last part also helps with data residency issues, which is becoming a pretty big deal for the EU.

    • cooljacob204@kbin.social
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      Something to consider is a monolith can have different entry points and a focused area of work. Like my web application monolith can also have email workers, and background job processers all with different container specs and scaling but share a code base.

      And coming from a background where I work heavily with Postgres a bunch of smaller segregates databases sound like a nightmare data integerity wise. Although I’m sure it can be done cleanly there are big advantages with having all your tables in one database.

      • Renacles@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        I see, I’m definitely biased towards micro services after years of dealing with horribly made monoliths but I see what you mean.

        At the end of the day I think both approaches have pros and cons.