Hacker News Reader

Comment by jpalomaki | Hacker News Reader

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

View on HN

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

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

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?

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.

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/inde...

You can’t just change your interface in a monolith either without breaking other parts of it.

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.

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.

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?

All other things being equal, 1 service is obviously better than 4,000 services to maintain.

Not that obvious, how do you coordinate people from several of teams working on it?

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.

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.

And what service would that be?

Reply on news.ycombinator.com