possibility to better utilize used hardware resources
possibility to scale individual components horizontally (in a monolith scenario you have to scale the whole application)
possibility to hibernate individual software components if functionality is not needed / disabled by the user
Drawbacks of a distributed modular system
overhead through more services/processes
overhead through network data processing
additional energy consumption through network devices due to data transmission between services
overhead through distributed transactions (if needed)
Conclusion
Depending on the scenario, the drawbacks of a distributed modular system can lead to a higher energy and resource consumption in the end.
For example, if we look at microservices as a possible architectural style for an elastic, modular system, the following disadvantages compared to a monolithic system should be considered:
overhead through more services/processes (e.g. many JVMs instead of only a few)
overhead through network data processing
additional energy consumption through network devices due to data transmission between services
overhead through distributed transactions (if needed)
Not every application requires fine-grained scalability. If there is a predictably low load in the respective use case or all components of the system are always exposed to a constant load, a fine-granular architecture can ultimately have a negative impact on resource efficiency.
I therefore don't think it is possible to make a general statement. Every application requires different trade-offs and always striving for the best possible scalability can also lead to problems.
With regard to the quality aspect of modularity:
You naturally want modularity in any software application that will be used in the long term to enable better maintainability. However, a modular system can also be realized with a monolith. Modularity does not necessarily have to be realized with a distributed system.
Modularity is fundamental to the composability of software packages and to their rapid development and deployment. However, the prevalent approach to achieving it can lead to significant software bloat, which is detrimental to power, performance, and energy efficiency.
bhattacharya.etal.2011.softwarebloatwasted
The real issue isnβt modularity itself but that, because of the difficulty in modularizing functions exactly as needed, programmers inadvertently introduce superfluous processing and data overhead for reuse.
In terms of database calls, software consisting of fewer modules could require less calls while significantly more data is transferred per call. When software consists of more modules, an increase in database calls could be observed with the potential that less data is transferred per call, i.e. the calls are more fitted to the process at hand. In this case less CPU capacity is required for processing the call, lowering the EC per call.
Although modularity can positively affect the EC of software [35], more modules also implies a higher communication load. When the number of modules increases, depending on the deployment, the communication load that is induced on the infrastructure also increases.
Ineffective use of hardware is a common source for energy inefficiency and is one of the triggers to consolidate the number of active servers within a data center. From an EC point of view there is less hardware in absolute terms reducing the idle energy consumption and the available hardware is used more effectively.
The use of intermediaries and abstractions (so important for modifiability) increases the resources consumed in processing an event stream. Hence removing these intermediaries typically improves latency and throughput. This is a classic modifiability/performance tradeoff.
Separation of concerns, another foundation of modifiability, can also increase the overhead necessary to service an event if it leads to an event being serviced by an ensemble of components rather than a single component. The context switching and inter-component communication costs result in increased energy consumption, particularly when the components are on different nodes on a network. A strategy for reducing computational overhead and energy demands is therefore to co-locate resources and remove intermediaries and abstractions. Co-location may mean hosting cooperating components on the same processor to avoid the time delay of network communication or it may even mean putting the resources in the same execution container, to avoid even the expense of a method call and its context-switching costs.
Amongst these quality tradeoffs, the greatest importance is to gain an understanding of the consequences of modularization (and buy versus build) decisions. This has received scant attention from the research community. Capra et al. [17] reported on a study where they concluded that the use of frameworks and external libraries is detrimental to the energy efficiency of large applications.