Infrastructure vs. Config as Code
Infrastructure vs. Config as Code
What does the modern stack for an application or service in an environment look like?
Join the DZone community and get the full member experience.
Join For Free
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.
Like This Article? Read More From DZone
Published at DZone with permission of Paul Hammant , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}