
Show HN: Introducing the Template Store for OpenFaaS - alexellisuk
https://www.openfaas.com/blog/template-store/
======
75dvtwin
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
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
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.

