After the article on Operation Hates Agile, here comes next, how to move from Operations to GitOps.
IaC is the replacement of traditional operation. It allows enterprises to control changes and manage the configuration settings in cloud environments more efficiently.
First, we need to know what contained inside "Infrastructure as Code" or IaC. There are 3 characteristics in IaC:
- Imperative and Declarative
- Mutable and Immutable
- DevOps
Imperative Vs. Declarative
Most IaC is declarative in nature. However, we can always make changes to the cloud environment with both imperative or declarative automation.
To make imperative automation changes to cloud infra, we use cmdline interface (CLI). It directs changes to the cloud first within a container, then virtual machine (VM), and then virtual private cloud, through a script. This is a detailed checklist, but if the configuration needs to be changed after the push to multiple machines, the steps and the script would have to be repeat.
A declarative automation approach requires goal creation. For example, rather than using the CLI and listing the exact step-by-step configuration for a VM, you’d simply state that you want a VM with, say, a domain attached, and then let the automation take over. The declarative approach (most of the time in YAML) enables you to more easily state what needs to be accomplished by the automation tools.
Mutable Vs. Immutable
Mutable means that it is prone to change. A virtual machine is an example of mutable infrastructure.
Immutable infrastructure cannot be changed once deployed, such as container/docker. Changes will still occur, but they are made to the original declarative statements. Once the changes are ready, all like devices or configurations are changed consistently.
Most of the time, we use both imperative and declarative automation methods interchangeably to manage IaC. This may raise an issue called Configuration Drift.