6 ms·

Have you had to deal with a microservices environment? Because there's significantly more operational and architectural complexity with a distributed system com

by romanhn 27d ago

Have you had to deal with a microservices environment? Because there's significantly more operational and architectural complexity with a distributed system compared to a monolith. Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. I would generally not recommend adding all this overhead unless absolutely necessary. Or at least that was the recommendation pre-AI, but I don't think I've changed my mind on it yet.

win311fwg 27d ago
> Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.
- ulrikrasmussen 27d ago
  Then it sounds like you can only have a true microservice architecture if your application doesn't really need transactional guarantees, consistency or fault tolerance.
  - win311fwg 27d ago
    Then you must have heard the wrong thing. Oh well. You can't communicate with everyone.
    - ulrikrasmussen 27d ago
      Then please help me understand, it is entirely possible that I misunderstood you, but you are not clarifying your point.
      - win311fwg 26d ago
        You were happy with your interpretation before. Perhaps that's sufficient?
  - kstenerud 27d ago
    Microservices are just another "cache" level in the end. They can make sense in the right situations, but you need to make your architecture deliberate in order to reap its advantages. Idempotent services are an easy win, and also places where you have data locality (similar to cache locality, just a few levels lower). At the end of the day, it comes down to: - how far does the data have to travel, and at what cost? - how much latency can your process tolerate? - how much unreliability can your process tolerate? - where and how do you isolate resources that are concurrency sensitive? - what's the infrastructure going to cost?

by romanhn 27d ago

win311fwg 27d ago

> Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.

ulrikrasmussen 27d ago
Then it sounds like you can only have a true microservice architecture if your application doesn't really need transactional guarantees, consistency or fault tolerance.
- win311fwg 27d ago
  Then you must have heard the wrong thing. Oh well. You can't communicate with everyone.
  - ulrikrasmussen 27d ago
    Then please help me understand, it is entirely possible that I misunderstood you, but you are not clarifying your point.
    - win311fwg 26d ago
      You were happy with your interpretation before. Perhaps that's sufficient?
- kstenerud 27d ago
  Microservices are just another "cache" level in the end. They can make sense in the right situations, but you need to make your architecture deliberate in order to reap its advantages. Idempotent services are an easy win, and also places where you have data locality (similar to cache locality, just a few levels lower). At the end of the day, it comes down to: - how far does the data have to travel, and at what cost? - how much latency can your process tolerate? - how much unreliability can your process tolerate? - where and how do you isolate resources that are concurrency sensitive? - what's the infrastructure going to cost?