It all started with Ruby. Ruby's syntactic sugar inspired the "syntactic sugar" of tooling, primarily Bundler and Rspec. Tooling, for what felt like the first time, became a first class citizen. Ruby's tooling made Heroku possible: ie, reproducible builds across; dev, testing, staging and production environments. Heroku's success was based on the primitives of the Twelve-Factor App[1]. The 12 factors (and therefore Heroku) were fundamentally designed around the already-old lightweight virtualisation technology of LXC. The success of Heroku paved the way for Docker. The success of Docker created the world in which Kubernetes makes sense.
To be blunt: if you don't understand the relevance of Kubernetes, or whether it's relevant to you, you don't understand the benefits of the 12 factors in their broadest sense. The 12 factors are much, much more than just "How To Deploy On Heroku".
Copypasting the 12 factors:
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
How do you pass hierarchical config? In JSON, YAML, TOML, etc., it's easy to group env vars, but how do you do that with env vars? LOGGING__HANDLER__FORMAT, LOGGING__HANDLER__ARGS__ARG1, LOGGING__HANDLER__ARGS__ARG2 ? If so, that looks positively awful. If the solution is passing a YAML or JSON string in the env variable, that sounds even worse than having a config file that the app reads.
>> it’s easy to mistakenly check in a config file to the repo
Add it to the ignore file. Someone would really have to force commit it to get into version control. Plus, even if it's stored in env vars, you're going to commit the values somewhere be it your Ansible secrets, SaltStack yml, Chef or Puppet repo, whatever.
To be fair, that's the only point I contend with. The rest is very reasonable.
Goodness gracious. That's dreadful and exactly what I feared the effect of that rule would be were it followed strictly. It looks like a hacky workaround to an unnecessary problem.
I’ve always thought a reasonable pragmatic solution is to force configuration files to be loaded based on an optional env variable. Kubernetes can easily mount a complex configuration file via a volume or configmap (configmapgenerator is awesome). As long as the path is configurable and the env var is documented - it’s not so bad.
This ignores the reality that kubernetes came from google and was based on existing (long lived) tooling. Docker is "some shell scripts around namespaces and cgroups" (also long lived, existing tooling).
The fact that there is public interest in these things _maybe_ you can attribute in some way to ruby but not the existence of them IMO.
It all started with Ruby. Ruby's syntactic sugar inspired the "syntactic sugar" of tooling, primarily Bundler and Rspec. Tooling, for what felt like the first time, became a first class citizen. Ruby's tooling made Heroku possible: ie, reproducible builds across; dev, testing, staging and production environments. Heroku's success was based on the primitives of the Twelve-Factor App[1]. The 12 factors (and therefore Heroku) were fundamentally designed around the already-old lightweight virtualisation technology of LXC. The success of Heroku paved the way for Docker. The success of Docker created the world in which Kubernetes makes sense.
To be blunt: if you don't understand the relevance of Kubernetes, or whether it's relevant to you, you don't understand the benefits of the 12 factors in their broadest sense. The 12 factors are much, much more than just "How To Deploy On Heroku".
Copypasting the 12 factors:
1. https://12factor.net/