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.

  • 1984
    link
    fedilink
    arrow-up
    6
    ·
    edit-2
    5 months ago

    I think micro services are useful if you need to scale your application parts independently from other parts.

    But I think now everyone uses micro services because it fulfills the developer dreams of being able to write code independently, and have it run on your computer inside docker.

    So using docker is probably the best part about micro services. The downside of all this is the extra complexity in having them talk to eachother and that is the difficult part. When everything goes over the network and is async, you run into lots of potential error scenarios that must be handled. And each call is a million times slower compared to local.

    It’s not the future. It’s just a tech trend and it will be something else in a few years. Tech never stays the same for very long.

    • Thorry84@feddit.nlOP
      link
      fedilink
      arrow-up
      1
      ·
      5 months ago

      But monolitic apps run fine inside of docker? I’ve tried a couple of home automation tools using docker. They were all monoliths, but we’re able to be run with a single docker command. It included a webserver and database server, plus the entire app and dependencies inside the docker container.

      • CookieOfFortune@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        5 months ago

        It’s been said before that microservices solve organizational problems. When you’re forced to go through official APIs, each team becomes responsible for their own connections to other teams. If you’re at a scale where a few people can be responsible for the entire system there’s really no benefit.

        • 1984
          link
          fedilink
          arrow-up
          3
          ·
          5 months ago

          That’s a good way to put it. It’s also possible to use Kafka message queues to share data with other teams instead of using docker apps with rest apis. I’ve seen it done pretty well. But depends on what needs to be shared and how flexible it needs to be.

          • CookieOfFortune@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            5 months ago

            The actual protocol doesn’t matter, just that the team has to own it and publish it and other teams must use these APIs. Otherwise you get teams adding and modifying other teams code and you end up with the monolith anyways.