3 ms·

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 b

• 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.