Unfortunately this is not very useful. 'Modularity' is not a guarantee of good software design or operational practice. You can develop a "module" that is tigh

Unfortunately this is not very useful. 'Modularity' is not a guarantee of good software design or operational practice. You can develop a "module" that is tightly integrated with other "modules", making it unusable without the other "modules". This means you have one software component that's effectively split into two, and at least one is unusable on its own. This creates dependency issues, and design issues, as now the second component needs to closely track development of the first component. What's the point of the second module? None from the application's perspective; but it helps with Conway's Law (the worst reason for a software design decision). In addition, "deployment" is not a singular concept. How is a monolith a "single unit of deployment" if it depends on a database with a changing schema? You have to deploy schema changes intentionally, and typically first, but with code that is backwards/forwards compatible. What's a deployment then? Is it a multiple stage process with multiple components? Or is the monolith somehow a "single unit of deployment", even though it entirely depends on the database which has its own "single unit of development", with the first being dependent on the second? (the answer is: a 'deployment' isn't a fixed concept; there is merely systems, and their components, and an order of operations to make changes without impairing system function) Good system design depends on other, more specific concepts, like loose coupling, high cohesion, single responsibility, encapsulation, backwards-compatibility, immutability, versioning, and change management, to name a few. Merely making modules doesn't mean much; monoliths (like microservices), if not mindful, meander into mudballs. It's also an overstatement to claim that microservices are inherently more complex than monoliths. You can easily end up with an overcomplicated monolith too. In fact you can easily end up with an overcomplicated anything. The difference with microservices is you're not [supposed to] make assumptions about data relationships, and you do have to preserve whatever functionality you expose that others depend on. And please remember that monoliths and microservices aren't competing, as if one is supposed to be better than the other. They are just different, like apples and oranges. They have specific [and different] design and function implications. Use them properly as needed. You should be mixing them, not just making one thing in one way as if your whole company must do all things "the one twue way". (Examples [not canonical]: dhcpd is a microservice; dns is a collection of microservices; your browser is a monolith; a web app may be a microservice or monolith (or both); etc)