Serious question. I know there are a lot of memes about microservices, both advocating and against it. And jokes from devs who go and turn monoliths into microservices and then back again. For my line of work it isn’t all that relevant, but a discussion I heard today made me wonder.

There were two camps in this discussion. One side said microservices are the future, all big companies are moving towards it, the entire industry is moving towards it. In their view, if it wasn’t Mach architecture, it wasn’t valid software. In their world both software they made themselves and software bought or licensed (SaaS) externally should be all microservices, api first, cloud-native and headless. The other camp said it was foolish to think this is actually what’s happening in the industry and depending on where you look microservices are actually abandoned instead of moving towards. By demanding all software to be like this you are limiting what there is on offer. Furthermore the total cost of operation would be higher and connecting everything together in a coherent way is a nightmare. Instead of gaining flexibility, one can actually lose flexibility because changing interfaces could be very hard or even impossible with software not fully under your own control. They argued a lot of the benefits are only slight or even nonexistent and not required in the current age of day.

They asked what I thought and I had to confess I didn’t really have an answer for them. I don’t know what the industry is doing and I think whether or not to use microservices is highly dependent on the situation. I don’t know if there is a universal answer.

Do you guys have any good thoughts on this? Are microservices the future, or just a fad which needs to be forgotten ASAP.

  • assaultpotato@sh.itjust.works
    22·
    4 months ago

    The reality is, as always, “it depends”.

    If you’re a smaller team that needs to do shit real fast, a monolith is probably your best bet.

    Do you have hundreds of devs working on the same platform? Maybe intelligently breaking out your domains into distinct services makes sense so your team doesn’t get bogged down.

    And in the middle of the spectrum you have modular domain centric monoliths, monorepo multi-service stuff, etc.

    It’s a game of tradeoffs and what fits best for your situation depends on your needs and challenges. Often going with an imperfect shared technical vision is better than a disjointed but “state of the art” approach.

    • Thorry84@feddit.nlOP
      2·
      4 months ago

      Thanks for your excellent response. The way these two sides were talking it seemed like there is no actual middle ground. But from what you say there actually is.

      • Tanoh@lemmy.world
        4·
        4 months ago

        Online discussions tend to be very polarising.

        Nothing special about this topic, but something you should always keep in mind about any topic.

      • assaultpotato@sh.itjust.works
        3·
        4 months ago

        Tech people tend to be very black-and-white when discussing ideology. Reality is more forgiving.

        If you can get your hands on it, the opening chapters of “Practical Event Driven Microservices Architecture” by Hugo Rocha gives a reasonable high level view of when you might decide to break a domain out of a monolith. I wouldn’t exactly consider it the holy grail of technical reading, but he does a good job explaining the pros and cons of monolith v microservices and a bit of exploration on those middle grounds.