Taking sides in the debate of microservices v. monolith gets in the way of doing the right thing for our customers. Sometimes, we need microservices. Sometimes, we need a monolith. Most of the time we are better off somewhere between these extremes.

We should stop talking about monolith vs. microservice and instead have a more nuanced debate about right-sized services.

  • thanks_shakey_snake@lemmy.ca
    6·
    1 year ago

    I think there’s alot of good wisdom and perspective in this article, but man he has some weird takes, lol… e.g.:

    A microservices application is just a monolith, but with the number of services dialed up and the sizes of the services dialed down.

    Like… There’s a charitable interpretation, I guess, but that’s such an odd way to put it.

    • corytheboyd@kbin.social
      9·
      1 year ago

      I’ve heard it much better described as a “distributed monolith”, which makes complete sense to me. It’s what you get when you “break up” a monolith into “services”, but the spaghetti is still there, it’s just distributed across services now. You have to actually eliminate tight coupling, define the correct boundaries, and vigilantly respect them. All of which should happen from within the monolith first, ideally, where you still have the massive luxury of one codebase to deal with as you make the huge refactors necessary before completely decoupling into services. Even better, do this required prerequisite work and discover that your monolith is actually… fine.