4 ms·

I'm my opinion Docker solves this fairly well, by basically having a declarative virtual machine. It's a lightweight representation of the dependencies of the a

by gitgud 8y ago

I'm my opinion Docker solves this fairly well, by basically having a declarative virtual machine. It's a lightweight representation of the dependencies of the application. Instead of bundling all dependencies into an executable Jar, you can define the environment for you application. Then it's still a command line switch away. What your suggesting is the operating system is the hat. You will have all sorts of configuration issues on that level rather than the Docker level.... I guess you can't escape the hat!

75dvtwin 8y ago
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.

by gitgud 8y ago

75dvtwin 8y ago

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.