2 ms·

not directly related, but I have feeling that, sometimes, we, as software designers -- under-estimate the value proposition of a 'single executable/single jar'

not directly related, but I have feeling that, sometimes, we, as software designers -- under-estimate the value proposition of a 'single executable/single jar' distribution, for backend services. If, at design stage we spend a bit more time 'designing' the run-time dependencies and packages of caching frameworks, reverse proxy services, load-balances -- we should end up with more cohesive, single executables/jars/assemblies. the same assembly, could then be deployed at multiple hosts/end points and started up with a switch at the command line, indicating what particular subsystems need to be executed. Single file distribution should also help to eliminate, or reduce the headaches that ops/customer teams have to go through when they are deployment our solutions. I appreciate that docker and template attempt to solve the ease of deployment from another angle: given all decoupled, loosely related artifacts -- here is a 'hat' that manages them all. But working on a deployment model at the design time, rather than as an after thought (or delegated to another team of devops/etc) -- I think, would help.

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.

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.