Further Reading

The approach taken by ConfigHub is based on many years of experience dealing with and working on configuration management challenges.

References

• Borg, Omega, and Kubernetes: advocated for "a clean separation between computation and data."
• Original Kubernetes Configuration Proposal: advocated decoupling of configuration generation and reconciliation. "Once we have generated a set of API objects, it should be possible to perform a number of management operations on them, such as creation, update, or even deletion." Led to kubectl and kubectl apply. See also On using the Kubernetes Resource Model for Declarative Configuration.
• Declarative Application Management in Kubernetes: advocated "configuration data written in a familiar and easily manipulated format." Led to kustomize.
• The tension between flexibility and simplicity in Infrastructure as Code
• Complexity and toil in Infrastructure as Code
• Infrastructure as Code is Artisanal Automation
• The Factory metaphor makes sense for building applications, but not for deployment and operations
• The insidious problem of configuration sprawl
• Making mass changes to Infrastructure as Code
• Fundamental challenges with Infrastructure as Code imply the language doesn’t matter
• Modularity and blast radius in Infrastructure as Code
• Why configuration drift is so hard to avoid in practice
• How software-engineering instincts clash with Infrastructure as Code
• The Unidirectionality of Infrastructure as Code creates Asymmetry
• The 12 Anti-factors of Infrastructure as Code
• Variant generation is the primary capability of Infrastructure as Code
• I shouldn’t have to read installer code every day
• Kubernetes Configuration in 2024