There are a handful of automation concepts that organizations should be aware of to ensure success.
Idempotence
When it comes to automation, idempotence means that once a specific task is run, rerunning it will not alter the initial result. For example, if idempotent automation exists to deploy three virtual machines, running the automation will result in three deployed virtual machines. Rerunning the automation, whether once or a thousand times, will not alter the environment. Conversely, if non-idempotent automation exists for the same task, it will deploy three new virtual machines each time it is run.
Automation tools are either idempotent or non-idempotent, so organizations should choose a tool that best aligns with their operational practices. The advantage to using idempotent tools is that they prevent unexpected results when automation is run inadvertently. Organizations that require fine-grained control over every step taken by an automation tool may prefer a non-idempotent tool. Still, it is prudent to test both idempotent and non-idempotent tools to find the best fit.
Declarative vs. Imperative
Expressing how to automate a given task is done via a data model. Data models follow a syntax that is readable by both humans and computers. They are frequently referred to as a “language,” even though they are not always actual programming languages. Standards-based data models include JSON and YAML. HashiCorp HCL (HashiCorp Configuration Language) is an example of a proprietary data model.
Automation tools and their associated data models can be declarative or imperative. Imperative automation is like a recipe or directions to a destination. Each task that needs to be executed is specified, as is the order to execute them. Declarative automation specifies the desired end state, and it is up to the automation tool to determine what needs to be done to reach that state.
Using the same example automation that creates three virtual machines, in an imperative model, three new virtual machines would be created each time the automation is run. In a declarative model, three new virtual machines would be created the first time the automation runs, but no new virtual machines would be created on subsequent executions. Now, suppose the automation was updated to create five virtual machines. In an imperative model, an additional five virtual machines would be created. In a declarative model, only two new virtual machines would be created since three virtual machines have already been created.
As with idempotence, organizations should choose a tool that fits the model best aligning with their operational practices. Declarative tools are typically easy to use but are not as flexible as imperative tools. Organizations that require fine-grained control over every step taken by an automation tool may prefer an imperative tool. The same advice given for idempotence applies. Organizations should test imperative and declarative tools in a sandbox environment to weigh the pros and cons.
Source Control and Pipelines
Automation data models and other configuration information are saved in files. Storing these files in a source control system, like Git , provides several benefits. Developers use source control to track and review changes to source code and collaborate with other developers. Organizations implementing automation should follow these same practices by storing all automation-related files in a Git repository (or similar solution).
Git can be combined with a Continuous Integration/Continuous Development (CI/CD) pipeline to trigger automation whenever the data models stored in source control are changed. This practice allows for the automation data models to represent the “source of truth” for the desired state of an organization’s infrastructure. Whenever a change is needed, a typical Git workflow is followed to review proposed changes and merge them into the repository. Accepting a merge request (a.k.a. a pull request) triggers the pipeline to execute, running the automation to adjust existing infrastructure based on the changes to the data model.
Combining source control and pipelines for automation requires planning and testing to be successful, but the result is a compelling model for deploying and maintaining cloud-based infrastructure and services.
Immutable Infrastructure
Automation enables organizations to embrace the practice of immutable infrastructure. Traditionally, infrastructure components are mutable, which is another way of saying that the components can be changed or reconfigured. Virtual machines and other components are deployed, configured, and reconfigured over long periods of time. These environments are susceptible to configuration drift, slow memory leaks, or full disks. Immutable infrastructure is used to mitigate these issues. With immutable infrastructure, existing components are decommissioned, and new components are deployed whenever a change is needed. The same process is followed when a component is unhealthy – it is simply removed and redeployed. Automation drives the deployment of components and ensures that the environment is in its desired state.
