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
    2·
    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.