4 ms·

There's an an interesting HN comment[1] from 2020 by former Uber engineer, which discusses the complexity a bit. It's more about UI, but the thread discusses th

There's an an interesting HN comment[1] from 2020 by former Uber engineer, which discusses the complexity a bit. It's more about UI, but the thread discusses the backend as well. In brief something that may look super simple for the user (like handling payments) is actually quite complicated when you cover all the market, different payment types etc. And all this carries to the backend as well. [1] https://news.ycombinator.com/item?id=25376346 https://news.ycombinator.com/item?id=25376346

lamontcg 3y ago
Do all of those need to be microservices or you could you instead have one monolithic payment service that handled all those use cases?
- scarface_74 3y ago
  And then every time you had a change, you would have to deploy everything and your surface of failure is greater. What would a monolith buy you?
  - jgraettinger1 3y ago
    Not having to evolve or understand or staff 4,000 micro services. An ability to easily change the boundaries of your conceptual components, because they WILL be wrong now or in the future.
    - scarface_74 3y ago
      You still have to understand your boundaries when you have a large monolith unless you have one big ball of mud. Even with a well constructed monolith, you need to have well defined “services” with contractual interfaces. You don’t have to understand 4000 services to make one change anymore than I need to understand the entire boto3 library when I am building on top of it. https://boto3.amazonaws.com/v1/documentation/api/latest/index.html https://boto3.amazonaws.com/v1/documentation/api/latest/inde... You can’t just change your interface in a monolith either without breaking other parts of it.
    - a_vanderbilt 3y ago
      Managing a numerically large set of services has its own challenges, but it pales in comparison to the complexity of a monolithic service serving the same functionality. As the other poster already pointed out, such a behemoth would be a nightmare to change at all. It would also be a scalability and and reliability nightmare. We migrated away from monoliths because they don't work in modern compute architectures.
    - folmar 3y ago
      It might be easier if you have the same API for payment microservices, but each different implementation in a different service, so approximately 100 times less distinct APIs than microservices.
- pc86 3y ago
  Of course you could, just like you could do this in 2000 less-well-defined microservices, or 8000 more finely-grained ones. The question is what makes you think 1 service is immediately better than however many payment services there are now?
  - lamontcg 3y ago
    All other things being equal, 1 service is obviously better than 4,000 services to maintain.
    - isbvhodnvemrwvn 3y ago
      Not that obvious, how do you coordinate people from several of teams working on it?
      - MichaelZuo 3y ago
        IBM managed to coordinate several hundred people on a single software product for decades on end. Even Microsoft managed to do so for multiple products while also stack ranking the teams. And I doubt there's a single service, even payments, that's as technically complex as Excel.
      - lamontcg 3y ago
        Do you really have 4,000 teams working on payments? And I'd agree with the other child comment that the monolith can always be broken into separate components which are owned by different teams.
- s3p 3y ago
  And what service would that be?
scarface_74 3y ago
And also certain states and localities have different requirements for ride share. I noticed this in NYC and Seattle

lamontcg 3y ago

Do all of those need to be microservices or you could you instead have one monolithic payment service that handled all those use cases?

scarface_74 3y ago
And then every time you had a change, you would have to deploy everything and your surface of failure is greater. What would a monolith buy you?
- jgraettinger1 3y ago
  Not having to evolve or understand or staff 4,000 micro services. An ability to easily change the boundaries of your conceptual components, because they WILL be wrong now or in the future.
  - scarface_74 3y ago
    You still have to understand your boundaries when you have a large monolith unless you have one big ball of mud. Even with a well constructed monolith, you need to have well defined “services” with contractual interfaces. You don’t have to understand 4000 services to make one change anymore than I need to understand the entire boto3 library when I am building on top of it. https://boto3.amazonaws.com/v1/documentation/api/latest/index.html https://boto3.amazonaws.com/v1/documentation/api/latest/inde... You can’t just change your interface in a monolith either without breaking other parts of it.
  - a_vanderbilt 3y ago
    Managing a numerically large set of services has its own challenges, but it pales in comparison to the complexity of a monolithic service serving the same functionality. As the other poster already pointed out, such a behemoth would be a nightmare to change at all. It would also be a scalability and and reliability nightmare. We migrated away from monoliths because they don't work in modern compute architectures.
  - folmar 3y ago
    It might be easier if you have the same API for payment microservices, but each different implementation in a different service, so approximately 100 times less distinct APIs than microservices.
pc86 3y ago
Of course you could, just like you could do this in 2000 less-well-defined microservices, or 8000 more finely-grained ones. The question is what makes you think 1 service is immediately better than however many payment services there are now?
- lamontcg 3y ago
  All other things being equal, 1 service is obviously better than 4,000 services to maintain.
  - isbvhodnvemrwvn 3y ago
    Not that obvious, how do you coordinate people from several of teams working on it?
    - MichaelZuo 3y ago
      IBM managed to coordinate several hundred people on a single software product for decades on end. Even Microsoft managed to do so for multiple products while also stack ranking the teams. And I doubt there's a single service, even payments, that's as technically complex as Excel.
    - lamontcg 3y ago
      Do you really have 4,000 teams working on payments? And I'd agree with the other child comment that the monolith can always be broken into separate components which are owned by different teams.
s3p 3y ago
And what service would that be?

scarface_74 3y ago

And also certain states and localities have different requirements for ride share. I noticed this in NYC and Seattle