20200203 - CfgMgmtCamp 2020 - Configuration Management in 2020 and Beyond, Eric Sorenson

by Thierry de Pauw on

#cfgmgmtcamp

Configuration Management in 2020 and Beyond, Eric Sorenson @ahpook

IFTTT for DevOps ...?
puppet.com/project-nebula

intended as a Continuous Deployment service for cloud-native
but our users found it is interesting for all sorts of sysadmin

Book: Cloud Native Infrastructure defines Cloud-Native characteristics:

  • platform-enabled
  • resilient
  • agile
  • operable: control the app from the inside
  • observable

12 Factor Apps (from Heroku)

  • declarative config
  • clean OS contract
  • build fro cloud
  • enable CD

more characteristics ...

  • Ephemerality: shorter lifespan, short-lived lifecycle, cattle not pets
  • Cardinality: events have characteristics, not from which server they are coming but how fast they are coming in and how fast you can dig into it
  • Immutability: you can't change the state of running systems
  • Data...bility: the idea of having a declarative data model for our systems, configuration should move beyond code and get back into the data

=> outcomes from that list of properties for Configuration Management tools

Infrastructure as Code becomes Infrastructure as Software becomes Infrastructure as Data

  • @rjw1: Maybe infrastructure as data is the next level of infrastructure (@ahpook) #cfgmgmtcamp https://t.co/8gInWo2nrA

The Configuration Complexity Clock, Mike Hadlow, via @garethr and Cedric Charly

for config management tools

when you start a new application:
Hard-Coded values -> extract as Config Values -> application becomes part of the business and needs business logic: Rules Engine -> DSL

and then somebody comes along and says: this is far too complicated, let's start over again (and off you go).

the analogy for Cloud-Native ...

Taxonomy of Cloud-Native CM Tools:
Raw Config -> Generators -> Frontends with which you interact and does all the complex things behind the scenes -> DSL

Frontends:
- Helm
- Pulumi

DSLs
- Terraform: same complains as for Puppet over the years - when restrictions are enforced by a tool, people will find a way

Lessons learned

  • Complexity will chase you
    tools that are too simple, will shoehorn that complexity and you end up with YAML-engineering

  • Constraints and specifications above all else
    or: any sufficiently advanced YAML dialect is an indistinguishable form of a DSL
    you don't know which fields exist, which one are defined, which values they should have
    use something like JSON-schema to describe which fields are available

  • Stop making new DSLs
    rule #1: there are no new problems
    rule #2: if you think you have found a new problem, go back to rule #1