Advertisement
Advertisement

More Related Content

Similar to I Got 99 Problems and a Bash DSL Ain't One of Them(20)

Advertisement

I Got 99 Problems and a Bash DSL Ain't One of Them

  1. • 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)
  2. "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
  3. • 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
  4. The Drunken History of Configuration Management (First Generation) (Second Generation) (Third Generation) Scripts Mike Hadlow - The Configuration Complexity Clock
  5. Before (BC) Configuration Management
  6. • 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
  7. First Generation
 Configuration Management
  8. • IBM Acquires Tivoli • HP Acquires Opsware and Novadigm • BMC Acquires Bladelogic • Microsoft with WMI and Powershell The Big Four
  9. • 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
  10. Second Generation
 Configuration Management
  11. • CFEngine - 1993 - Mark Burgess • Puppet - 2005 - Luke Kanies • Chef - 2009 - Adam Jacob • Ansible - 2010 - Michael DeHaan The New Four
  12. Comment Section 
 Bryan McLellan Luke Kanies Ezra Zygmuntowicz Adam Jacob Tim Dysinger
  13. Why Chef Exists
  14. The Trinity of Configuration Management
  15. CM Tools Are Only As Good As Their Authors
  16. • 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)
  17. • 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)
  18. • Mostly Declarative • Fully Automated • Desired State • Cattle Not Pets • Consistent Environments (convergent) • Repeatable and Disposable • Not Immutable Second Generation Configuration Management Summary
  19. Citizens of the Plateau of Productivity
  20. • Vagrant • Packer • Terraform • Vault Enter “Kid” Midas
  21. Third Generation
 Configuration Management
  22. ▪ Immutable Infrastructure 3 Creating Consistency in the Pipeline
  23. “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
  24. First Generation Second Generation Third Generation
  25. Why Order Really Matters (SPC “68–95–99.7” Rule) • Variation • Converged Infrastructure • Immutable Infrastructure • Immutable Delivery
  26. • 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)
  27. • 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)
  28. • 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
  29. “The New Normal” Configuration Management
Advertisement