I probably failed to express a particular direction I was arguing for. I was imagining a particular approach where ./mysolution is the delivered artifact that

I probably failed to express a particular direction I was arguing for. I was imagining a particular approach where ./mysolution is the delivered artifact that has compiled in business logic modules, all the technical modules, eg in memory caches, etc (basically anything that does not demand on horizontally distributed infrastructure for a single instantiation). ./mysolution -start="myxyz_microservice" -start="myabc_microservice" -common_cfg=/etc/myxyz/common_config.cfg would allow to instantiate different parts of the system (by specifying different startup name) that use the same executable (jar/.net assembly) and the same config. on chosen set of hosts or containers. Clearly a few foundational services cannot be 'compiled' in. Analogy, may be a bit too far fetch, is why unikernels (eg includeos.org ) are attractive design approach. They simplify deployment, reasoning about versions of components(and therefore security), they and speed up cold restart time. That 'single jar' does not eliminate the need for OS containers (docker, bsd jails), of course. But because of common configuration, and compiled in parts -- the docker/ or host os configuration for such solutions, in my view, would be simpler than for the 'stitched together by configs, version dependencies, and config templates' solutions.