Hacker News Reader

Comment by jgraettinger1 | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com