These definitions help to provision/create a different kind of resources, compute, storage, communication services, network
For cloud-based infrastructures, we can use these definitions to create "virtual resources" and to configure them to be in a certain state. For example, we can create a virtual machine with an initial OS image and later install some software and configure it.
In a bare-metal environment, we can use the definition to configure a fixed number of machines and devices already defined in an inventory.
The goals of this practice are:
- Avoid server configuration drifting
- Avoid proliferation of Snow flake Servers.
- Reduce drastically the maintenance cost and the total cost of ownership.
- Allow easy and infrastructure evolution.
- Use development practices for the infrastructure (version control, testing, audit, collaboration, live documentation...).
- Create on-demand systems for development, QA, testing, and experimentation.
- Developers collaboration.
Cons: really, it's 2018... no, seriously I don't find a good reason to not to create infrastructure as code. And when the problem is that these resources are difficult or impossible to define using code or some kind of definition, we should avoid them as much as possible.
General Approaches and styles
- Push. We execute a tool that parses the definitions, calculate the changes to do and execute them.
- Pull. Each node/device have its definition and execute all the time in a loop executing the needed changes.
- Push + Pull. A combination of the previous ones, so we can push a change (when we need to be sure or force some changes) or wait until each node/device update its configuration
In summary, IaC is a core DevOps practice and is the base for a lot of the innovations and evolution that the cloud brings us. It is a must for modern development in the cloud and also very recommendable for on-premise deployments.
Other tech pills: