Microservices work well if your contracts are well-defined, domain knowledge is limited, your team is under the size of a pizza, and your platform needs are div

Microservices work well if your contracts are well-defined, domain knowledge is limited, your team is under the size of a pizza, and your platform needs are diverse. Eg: Some small teams prefer containers, other prefer managed containers (serverless), others prefer small VM's. SOA works well if your teams are larger and have larger domain (or end to end, however you want to call it) knowledge. Monoliths work well when the domain of the application is singular, the team is large, or if you're in prototyping. The big downside for monoliths is that their scaling model must be considered in advance or engineers can tactically corner themselves with architecture. That incurs big, expensive rewrites as well as time. While Conway's Law may be reflective of the enterprises use of (or overuse of) microservices I think it really has more to do with a different enterprise habit: understaffing and budget constraint. Microservices and client-side applications, from my perspective, very rarely have long-term maintainers. Instead, things get done in cycles and then for most of the year a given service does not receive anything besides some maintenance updates or low-hanging fixes. That makes it look like a microservice is expendable and easier to replace to the people who manage resources, staffing, and budgets. Thus, things now look "modular" to the people who fund the ship that everyone else drives.