Infrastructure as Code enables businesses to more efficiently control the changes and configurations in a cloud environment. The idea behind IaC is to bring practices found within DevOps that allow 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 regarding leveraging IaC is this: Do you want 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), which directs changes to the cloud first within a container, then virtual machine (VM), and then virtual private cloud, making those listed changes 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 creation goals. For example, rather than using the CLI and listing step-by-step the exact 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 allows you to more easily state what needs to be accomplished by the automation tools.
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. What is decidedly important regarding security is that a consistent application of configurations should be in place across the infrastructure.
An immutable infrastructure means, by definition, that it cannot be changed once deployed. It does not mean that changes will not occur. Rather, the changes are made to the original declarative statements. Once the changes are ready, then all like devices or configurations can be 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 requires developers to wait on production, or vice versa. If developers can request containers or virtual machines with the same level of stability that is applied to code through an automated request, then it becomes possible for a smoother and quicker deployment, knowing that the network and virtual machine configuration is made through a controlled system. Even better versioning is then easier to trace.