3 ms·

Imo there's zero difference between 'thousands of microservices' and 'one monolith with thousands of functions/classes/etc' in terms of effort required to make

Imo there's zero difference between 'thousands of microservices' and 'one monolith with thousands of functions/classes/etc' in terms of effort required to make it correct - both are still tiny interconnected pieces making up a whole, and you can separately unit test a function just as easily as you can separately e2e test a single microservice. They still make up some whole product that presumably does something as a whole that you actually care about, and the complexity inherent to that doesn't go away with either approach.

killthebuddha 1mo ago
1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.
alright2565 1mo ago
Sure there is. For thousands of classes/functions, I can test the boundaries between them in nanoseconds each. Integration tests are the important part, because with the quality of AI coding these days, unit testing is a waste of time. With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making it harder to understand, plus now to do the same integration test I need to understand N different build systems for each component.
- 0x696C6961 1mo ago
  You can also make breaking changes to internal APIs without versioning or release coordination. Just update all the call sites.
romanhn 1mo 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 1mo 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 1mo 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 1mo ago
      Then you must have heard the wrong thing. Oh well. You can't communicate with everyone.
      - ulrikrasmussen 1mo ago
        Then please help me understand, it is entirely possible that I misunderstood you, but you are not clarifying your point.
        win311fwg 1mo ago
        You were happy with your interpretation before. Perhaps that's sufficient?
    - kstenerud 1mo 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?
whateverboat 1mo ago
In fact microservices are arguably more complex. It is the reason why microkernels have not succeeded compared to monolith till now.
onion2k 1mo ago
The separation in micro services is hard to break though. You need to add an API on one side and a call on the other. In a monolith it's significantly easier to do something that has an unexpected impact somewhere else. For example, changing a shared object a singleton to a clone will give you race conditions all over the place. You just don't have that footgun in micro services.

killthebuddha 1mo ago

1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.

alright2565 1mo ago

Sure there is. For thousands of classes/functions, I can test the boundaries between them in nanoseconds each. Integration tests are the important part, because with the quality of AI coding these days, unit testing is a waste of time. With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making it harder to understand, plus now to do the same integration test I need to understand N different build systems for each component.

0x696C6961 1mo ago
You can also make breaking changes to internal APIs without versioning or release coordination. Just update all the call sites.

romanhn 1mo 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 1mo 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 1mo 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 1mo ago
    Then you must have heard the wrong thing. Oh well. You can't communicate with everyone.
    - ulrikrasmussen 1mo ago
      Then please help me understand, it is entirely possible that I misunderstood you, but you are not clarifying your point.
      - win311fwg 1mo ago
        You were happy with your interpretation before. Perhaps that's sufficient?
  - kstenerud 1mo 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?

whateverboat 1mo ago

In fact microservices are arguably more complex. It is the reason why microkernels have not succeeded compared to monolith till now.

onion2k 1mo ago

The separation in micro services is hard to break though. You need to add an API on one side and a call on the other. In a monolith it's significantly easier to do something that has an unexpected impact somewhere else. For example, changing a shared object a singleton to a clone will give you race conditions all over the place. You just don't have that footgun in micro services.