3 ms·

IAC promise was ease of re-creation. [My anecdotal] Reality shows that's not really the case. IAC automation helps to create 'easy parts' and to delete _everyth

by betaby 5y ago

IAC promise was ease of re-creation. [My anecdotal] Reality shows that's not really the case. IAC automation helps to create 'easy parts' and to delete _everything_. Creation of hard pars, the ones which involve state is still a problem. After many ears of using cfengine/chef/puppet/ansible/terraform I can say those tools don't help much with solving infra complexity. Early arguments were that 'nobody understand those shell scrips' or 'know manually edited configs'. Now the same shell script live inside container 'sidecars' and do 'pip install' from them and instead of manually altered configs we have k8s annotations with unpredictable 'far reaching' inter-references.

jjnoakes 5y ago
The hard stateful parts should be your data layer (replicated db, etc) and everything else should be cached stateless data. IAC for the stateful layer is tough but contained. IAC for the rest should be fairly recreatable quite quickly.
KronisLV 5y ago
> Now the same shell script live inside container 'sidecars' and do 'pip install' from them and instead of manually altered configs we have k8s annotations with unpredictable 'far reaching' inter-references. This sounds really wrong - installation of all of your dependencies should be run as a part of building the container for a particular version of your application, say, as a directive within the Dockerfile. That should also be done before any unit tests and integration tests are run against that container, well before it is deployed to any environment. The end result of doing that properly is a container that will work correctly until the end of time (or at least any vulnerabilities become apparent and a new version needs to be built, or for other reasons, such as bug fixes or added functionality). Furthermore, all of your IAC should be treated just like regular code, which means full descriptions and comments for any non-trivial parts, or even explaining why the trivial parts are there to begin with (the greater circumstances, links to change requests etc. that the actual code doesn't otherwise contain). If you can't look at any single piece of your code and understand both what it does as well as why it's attempting to do it, then clearly there is still more work to be done. Whether that's refactoring or documentation, however, depends on the circumstances. IAC doesn't absolve you from the need of having documentation. It simply allows you to lower the degree to which PEBKAC is a problem in manual deployments and allows you to document the actual code that does things, rather than creating .docx descriptions that no one will read.

by betaby 5y ago

jjnoakes 5y ago

The hard stateful parts should be your data layer (replicated db, etc) and everything else should be cached stateless data. IAC for the stateful layer is tough but contained. IAC for the rest should be fairly recreatable quite quickly.

KronisLV 5y ago

> Now the same shell script live inside container 'sidecars' and do 'pip install' from them and instead of manually altered configs we have k8s annotations with unpredictable 'far reaching' inter-references. This sounds really wrong - installation of all of your dependencies should be run as a part of building the container for a particular version of your application, say, as a directive within the Dockerfile. That should also be done before any unit tests and integration tests are run against that container, well before it is deployed to any environment. The end result of doing that properly is a container that will work correctly until the end of time (or at least any vulnerabilities become apparent and a new version needs to be built, or for other reasons, such as bug fixes or added functionality). Furthermore, all of your IAC should be treated just like regular code, which means full descriptions and comments for any non-trivial parts, or even explaining why the trivial parts are there to begin with (the greater circumstances, links to change requests etc. that the actual code doesn't otherwise contain). If you can't look at any single piece of your code and understand both what it does as well as why it's attempting to do it, then clearly there is still more work to be done. Whether that's refactoring or documentation, however, depends on the circumstances. IAC doesn't absolve you from the need of having documentation. It simply allows you to lower the degree to which PEBKAC is a problem in manual deployments and allows you to document the actual code that does things, rather than creating .docx descriptions that no one will read.