[simplotek]

> Okay, so your microservices are each very simple, but that made the interactions and resource provisioning very complex. What was the net gain?

The main misconception about microservices is that people miss why they exist and what problems they solve. If you don't understand the problem, you don't understand the solution. The main problems microservices solve are not technical, but organizational and operational. Sure, there are plenty of advantages in scaling and reliability, but where microservices are worth their weight in gold is the way they impose hard boundaries on all responsibilities, from managerial down to operational, and force all dependencies to be loosely coupled and go through specific interfaces with concrete SLAs with clearly defined ownerships.

Projects where a single group owns the whole thing will benefit from running everything in one single service. Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface.

[kqr]

> Once you feel the need to assign ownership of specific responsibilities or features or data to dedicated teams, you quickly are better off if you specify the interface, and each team owns everything begind each interface.

If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?

[simplotek]

> If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?