Infrastructure as Code (IaC) enables a business to automate provisioning methods to scale the cloud efficiently, saving money and time.
Infrastructure as Code enables businesses to more efficiently control changes and configurations in a cloud environment. IaC offers DevOps practices that enable developers and operations to work more closely on the deployment of virtual machines, the virtual networks that are constructed around them, and the application within.
One of the decisions that needs to be made to leverage IaC is whether to make changes to your environment with imperative or declarative automation. Most IaC is declarative in nature. Here’s a simple way to look at it: imperative vs. declarative is the difference between how the program should operate vs. what the program needs to accomplish.
To make imperative automation changes to your infrastructure, you might use a Command Line Interface (CLI). It directs changes to the cloud first within a container, then virtual machine (VM), and then virtual private cloud, in order, 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 redone.
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 enables you to more easily state what needs to be accomplished by the automation tools.
Mutable vs. immutable
Configuration drift is a big problem regarding the configuration of any and all parts of the infrastructure. This occurs when mutable infrastructure is in place. Mutable means that it is prone to change. As one part of the infrastructure changes, it becomes out of sync with the rest. It is very important for security that a consistent application of configurations be in place across the infrastructure.
Immutable infrastructure cannot be changed once deployed. 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. Consistency is necessary from a security perspective because hackers just need one door left open to get in. Closing every door in the same way complicates matters for the hacker.
Development, testing, and deployment of applications to a production environment often require developers to wait for production, or vice versa. Smoother, quicker deployment is possible when network and virtual machine configurations are made through a controlled system. Developers can then request containers or virtual machines through an automated request with the same level of stability that is applied to code. This results in better versioning that is easier to trace.
Related Articles
Related Research