Since 1993 (and possibly earlier), numerous configuration management engines have been created. Why are they important? Well, they provide the invaluable service of configuring computer systems at scale, delivering ways to ensure that only a specific version of the software is running, critical patches to OS applied and guaranteeing that fleet of machines and OSes have proper settings. The above is achieved by the operator describing desired system states and either manually or automatically applying state transition over the machine fleet. The advantages of such operation at scale are numerous:
- Software delivery can be achieved automatically.
- Changes to systems are codified and repeatable.
- Computers usually do not make mistakes (unless instructed).
- The fleet under configuration management system control is audited. Exceptions in software configuration can trigger compliance checks.
- A reduced number of operational staff is required to maintain a large fleet of machines.
The advent of virtualisation gave ways for virtual machines, networks, and data centres to be defined within configuration management systems via configuration files. These virtualised environments made one want to describe complex hierarchical configurations in a more concise way. This led to Infrastructure As A Code concept - the ways to define infrastructure from configuration files written in a programming language.
Transformation
The moment we talk about infra definition as a piece of code, we start talking about multiple aspects familiar to software engineering:
- Testing
- Continuous Integration
- Continuous Delivery
- Automated QA
These aspects reduce the cycle of software/infra delivery from several months to several hours, allowing empowered teams to deliver value to business quicker:
- Within a few hours, a hypothesis about the changed website layout can be rolled out and A/B tested against a cohort of users.
- A new trading algorithm can be deployed via an automated delivery mechanism.
- New phone models can be made available in the online store without hassle.
A smaller set of changes travel to production with a quick turn-around time, reducing the risk of failure. A whole stack of infrastructure and applications described in the code makes it easy to validate. A complete testing environment can be created on demand, providing each engineer with the capability to experiment with changes without interfering with each other’s work!
Boring Details of Convergence Cycle
In general process of converging infrastructure can be described in the picture below:
- Operator (1) defines the configuration change and commits (2) that change into the version control system.
- A commit triggers an update to the desired state (3) that the state manager cares about.
- State Manager can be an automated service that is always run (in Kubernetes) or service which holds state in the cloud (Cloud Formation), or a runtime environment that is manually triggered by the user (Terraform).
- The state manager does a reconciliation (4) between desired state (3) and the actual state (7) of the infrastructure
- A result of reconciliation is a convergence process applied to the cloud infrastructure (6)
- The result of convergence is the actual adjusted state of the system.
