This document summarizes the evolution of configuration management over four decades through three generations: - First generation used scripting and descriptive files for manual, ad hoc configuration. - Second generation introduced declarative languages and full automation with desired states but environments were convergent, not identical. - Third generation focuses on immutable infrastructure, consistency through automation from development to production, and disposable environments using techniques like infrastructure as code and immutable delivery.

2. • 40Years in IT/Infrastructure
• Exxon, Canonical, Chef, Dell, Docker
• Founder of 11 Startups
• Spanned 4 Decades of Technologies
• Author 12 Books
• Instigator of the Devops Movement (CAMS)
Who Am I… @Botchagalupe (John Willis)

6. "YAML is a poor format for an external DSL, just as
XML was. The popular configuration format du jour
is always misused this way"
YAML as data format is defensible. YAML as a
programming language is not. If you're programming, use
a programming language.
I feel like there is a large gap between shell scripts and Ansible. If
we draw a line, you end up with something like this.
Bash/Make => CFEngine=>Chef/Puppet => Ansible

7. • We started out with Shell Scripts (Before)
• Next created macro like definition files (First Generation)
• Next we created primitive based declarative languages (Second)
• Then we move back to definition files (Third Generation)
• Here we are .. Shell Scripts are back in vogue
The Irony of the Configuration Management
30 Year Arc

8. The Drunken History of
Configuration Management
(First Generation)
(Second Generation)
(Third Generation)
Scripts
Mike Hadlow - The
Configuration
Complexity Clock

9. Before (BC)
Configuration
Management

13. • Procedural (mostly script based)
• Manual and Adhoc (not automated)
• No Desired State
• Pets not Cattle
• Inconsistent Environments (divergent)
• Not Repeatable or Disposable
Before Configuration Management
Summary

14. First Generation
Configuration
Management

16. • IBM Acquires Tivoli
• HP Acquires Opsware and Novadigm
• BMC Acquires Bladelogic
• Microsoft with WMI and Powershell
The Big Four

17. • Loosely Declarative Mostly Descriptive
• Not Manual but Still Adhoc (not automated)
• No Desired State
• Not Pets or Cattle
• Inconsistent Environments (mostly divergent)
• Not Repeatable or Disposable
First Generation Configuration Management
Summary

21. Second Generation
Configuration
Management

23. • CFEngine - 1993 - Mark Burgess
• Puppet - 2005 - Luke Kanies
• Chef - 2009 - Adam Jacob
• Ansible - 2010 - Michael DeHaan
The New Four

24. Comment Section
Bryan McLellan
Luke Kanies
Ezra Zygmuntowicz
Adam Jacob
Tim Dysinger

25. Why Chef Exists

26. The Trinity of Configuration Management

27. CM Tools Are Only As Good As Their Authors

28. • Abstraction DSL’s are very powerful
• Self documenting
• High reusability code/modules
• Easier to provide data driven models
• Generally more consistent than scripted patterns
• Most major IaC products have good testing abstractions
Infrastructure as Code (Pro’s)

29. • Abstraction DSL’s have higher learning curve
• Complex edge case scenarios/failures
• Script/Shell primitives are used often
• Integration interfaces are more complex
• Infrastructure is built Just in Time (JIT)
• Knowns are not always Known
• Builds are convergent not congruent
Infrastructure as Code (Con’s)

30. • Mostly Declarative
• Fully Automated
• Desired State
• Cattle Not Pets
• Consistent Environments (convergent)
• Repeatable and Disposable
• Not Immutable
Second Generation Configuration Management
Summary

31. Citizens of the Plateau of Productivity

32. • Vagrant
• Packer
• Terraform
• Vault
Enter “Kid” Midas

33. Third Generation
Configuration
Management

36. ▪ Immutable Infrastructure
3
Creating Consistency in the Pipeline

38. “The least-cost way to ensure that the behavior of any
two hosts will remain completely identical is always to
implement the same changes in the same order on both
hosts.”
Order Matters

39. First Generation Second Generation Third Generation

40. Why Order Really Matters
(SPC “68–95–99.7” Rule)
• Variation
• Converged Infrastructure
• Immutable Infrastructure
• Immutable Delivery

41. • Least variation pattern
• Faster provision model
• Fits well with Microservices architectures
• Less reliance on Infrastructure as code
• Binary consistency from dev to prod
Immutable Delivery (Pro’s)

42. • DSL abstraction not as mature as Infrastructure as code
• Small changes are harder to manage
• Debugging is harder
• Need a good model for image management
• Not all delivery models fit well
Immutable Delivery (Con’s)

43. • Partially Declarative and Partially Descriptive
• Fully Automated
• Disposable Targeted State
• Cattle Not Pets
• Congruent versus Convergent Environments
• Repeatable and Disposable
• Immutable
Third Generation Configuration Management
Summary

44. “The New Normal”
Configuration
Management