Infrastructure vs. Config as Code

 from  here  , where the cloud native landscape project organizes its multi-contributor thoughts. 

(the red boxes are mine, though.)

the lower group is a subset of the technologies you’d use to provision variable infrastructure, including many of the pieces elsewhere in the diagram. that is infrastructure as code, a now well-understood thing. those salt/ansible/puppet/chef scripts are under source control, or you’re doing it very wrong.

the upper group is titled coordination and service discovery in the diagram. given that feature flags and other ancillary live application and service settings should be held in the same systems, i think of the grouping as “configuration as code” instead.

source control isn’t the only (or even main) choice as the backing store for configurable items in that group, though.  git2consul  exists for consul, but that is not mainstream. i think it should be, and that it will be in time.

here’s how i look at the modern stack for an application or service in an environment:

 from a previous blog entry:  provisioning, deployment, and application config cycles  .