In a world where DevOps tooling has made it possible to automate virtually every process and workflow using an Infrastructure-as-Code approach, the key question that DevOps teams must ask is no longer, “Should we use IaC?”
Instead, the question has become, “What should we not manage with IaC?”
In DevOps, Infrastructure-as-Code’s value is obvious. Configuring infrastructure as code saves time and reduces toil for engineers. It also increases consistency and minimizes the risk of errors triggered by human oversight.
It’s common to hear engineers talk about “100 percent Infrastructure-as-Code,” with managing every process with IaC as their goal. The reality, though, is that not every process in DevOps can or should be handled using IaC.
Instead of shooting for 100 percent IaC coverage, switching 99 percent of operations to an IaC model is a better goal — not just because it’s more realistic, but because, as I explain below, some IaC workflows create more problems than they solve.
So, what processes, exactly, are included in the 1 percent of processes that teams should manage manually rather than through IaC? The answer will vary from one organization to the next, but in general, there are three types of processes that fare better without IaC.
When Should You Code Manually Instead of Using IaC?
- When a process only happens once or twice a year.
- When a process relies on third-party resources.
- When you can’t easily recreate the resources needed for a process.
When Operations Are Infrequent
There’s an obvious and a less obvious reason why infrequent processes don’t need IaC.
The obvious reason is that the less often you perform a process, the less value you get out of managing it using code-based automation.
Less obvious, but just as important, is that the IaC templates you set up for infrequent processes may break over time due to changes in resources that the processes address. IaC often needs maintenance due to shifting technology or enterprise policy.
As a result, engineers may have to rework their code every time they use it, resulting in the total time and effort spent maintaining the IaC workflow outweighing the time and effort it saves.
For example, consider secure sockets layer certificate renewals. Most organizations maintain a relatively small number of SSL certificates, and those certificates usually expire once every year or two. It’s easy to write IaC code that will automatically set up new certificates.
But it’s also quick and easy to manually renew them. And if you write code to renew SSL certificates, there’s a good chance that it won’t work a year or two later because your certificate authority will have made changes to its renewal process.
When Processes Depend on Third-Party Resources
If a DevOps process requires you to deploy third-party resources, manage it manually.
You can’t fully manage operations that you don’t control, and third-party resources are beyond your control.
For instance, if you want to set up an interconnection to boost network performance between a public cloud environment and a colocation facility, you typically need to work with a colocation or interconnection provider, which owns and manages the physical cabling that enables the connection.
Without being able to control when or how the third-party provider establishes the connection, you can’t write code to provision this type of resource automatically. It’s best to handle this process manually.
When You Can’t Recreate the Necessary Resources
Avoid managing processes with IaC that involve working with resources you can’t easily recreate or relaunch.
Why? Because if you can’t recreate a resource as part of an automated, code-based workflow, you can’t rerun your code on a recurring basis as you iterate upon and improve it.
As an example, consider sensitive information (such as passwords and encryption keys) stored in a secrets manager like Azure Key Vault. While Key Vault offers a feature called soft-delete that enables automated recovery of deleted secrets for a limited time, there’s no way to undelete secrets once the soft-delete window has closed.
As a result, you can’t easily repeat an IaC-based process that creates and deletes key vaults. You can only run the process once, making it challenging to iterate through test-edit cycles.
Infrastructure-as-Code often goes hand-in-hand with DevOps, and most teams should use IaC to streamline virtually everything they can. But the keyword here is virtually.
Some processes are just better without IaC, either because automating them using code is more trouble than it’s worth, or because they involve special types of resources (like those managed by third parties or ones that can’t be recreated on an iterative basis) that make IaC challenging to implement, at best.
