Modules, Monoliths, and Microservices
My observation is that much of industry does not care about any of these technical or security issues.<p>In theory microservices are technical artifacts, but what they tend to be are cultural artifacts.<p>Microservice adoption is often driven by cargo culting, or (better) a considered decision to work around a lack of organisational cohesion.<p>What microservices let you do is ship your org chart directly, and also map back from some functionality to an owning team. You know who to page when there's a problem and it's easier to tell who is late delivering and whose code is slow. In cultures with "lax" technical leadership (aka no everyone uses same thing mandate, I'm not judging) it lets teams use their favourite tools, for better or worse.<p>Other org related things are the ability to have independent (per team) release schedules. Separable billing. Ability to get metrics on performance, cost and failures that can be used as indicators of team performance and promotion material. Microservices can also act as "firewalls", limiting the impact a bad hire or team can have across your codebase.<p>None of this is intended to be negative judgement; microservices can (among other things), help teams feel a sense of agency and ownership that can be hard to maintain as org size scales up.