Skip to main content

Configuration as Code

Context​

Microservices are being adopted. Configurations can be changed at deploy or runtime.

Problem​

  • There is a lack of transparency of the deployment setup.
    • A deployment setup (infrastructure, configuration) is not easily reproducible.
    • There are some scripts/manuals, but there is no history of them (no version control).
    • It is unclear how different parts evolved, and if they are compatible.

Solution​

Use tools that allow configuration as code, and track this configuration code via version control.

The following configurations are candidates of configuration as code:

  • infrastructure preparation, e.g. via Ansible Playbooks
  • different deployment stages, e.g. via Helm Charts if deploying to Kubernetes
  • configuration values

Having code reusable instead of a manual embraces the cultural value of automation. The whole deployment process becomes more transparent and reproducible. Using version control to version this configuration lets us use the history for traceability of changes and compatibility.

Maturity​

More data required (only 3 sources).

Sources of Evidence​

L8:

  • 6th wave: continuous delivery tech
    • Examples: Ansible and Drone

L9:

  • Software-defined systems enabled devs to treat infrastructure as code
    • => infrastructure managed in automated, flexible, and efficient manner
    • complexity of infrastructure => potential not fully realized
    • Context: Containers

L24:

  • Deployment config may vary across different environments
  • if embedded in application code: changing environment would require changing source code
    • would make deployment demanding and error-prone
    • solution: specify env dependent configuration in artifacts external to source code
    • tool examples: Chef and Ansible
    • offer structured and centralized means to specify deployment at runtime

L31:

  • Context: Migration Practice MP11: Configuration Server
  • Separate repositories for source code and software configuration
    • need to synchronize
    • can evolve independently in general

L43:

  • infrastructure may be treated as code
    • supports rapid creation of testing and production environments
  • Power tools like Terraform make env simple to configure and use
    • rapidly spin up build, staging, production env based on a few scripts

LM43:

  • Context: SLR findings about microservices in DevOps
  • S16 presents Neo-Metropolis offers open source solutions
    • among others: Terraform, Ansible
    • to deal with scalability and elasticity

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C1-S1: currently automate deployment of JAR files via Ansible
    • seen as comfortable
    • but plan migration to Docker and Kubernetes to increas e operability
  • Portability attributed to containerization or tools like Ansible (by P1)

Interview A:

  • used first Ansible to automate infrastructure
  • now Helm Charts
  • Everything has to be in version control system
    • Infrastructure-as-a-service/software
    • deployment manual
    • Ansible Playbooks
    • Helm Charts
    • Configurations
  • (+) traceability
  • (+) compatibility traceable
  • => Configuration as Code