Derek Ashmore, Application Transformation Principal, Asperitas, says that to thrive at DevOps, recognizing when you should not use IaC is just as critical as taking advantage of this methodology wherever it makes sense.
The key question that DevOps teams must answer today is no longer “Should we use Infrastructure-as-Code?”
In a world where DevOps tooling has made it possible to automate virtually every process and workflow using an Infrastructure-as-Code (IaC) approach, deciding to take advantage of IaC at almost every opportunity is the obvious choice.
Instead, the question that really matters is “What should we not manage via IaC?”
In almost all businesses, there are some aspects of DevOps operations that teams shouldn’t handle through IaC – even if doing so is technically possible.
To explain this point, allow me to discuss the limitations of IaC-based automation and offer guidance on identifying processes that are not good candidates for IaC.
99% vs 100% Infrastructure-as-Code
In the context of DevOps, the value of Infrastructure-as-Code is obvious. Not only does configuring infrastructure as code save time and reduce toil for engineers but it also increases consistency and minimizes the risk of errors triggered by human oversight.
For this reason, it’s not unusual to hear DevOps teams talk as if managing every process via IaC is their goal. It has become commonplace to hear engineers talk about “100% Infrastructure-as-Code” as the goal they are striving for.
The reality, though, is that not every process in DevOps can or should be handled using IaC. Instead of shooting for 100% 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.
Deciding when not to use IaC
But what, exactly, are the 1% of processes that teams should not manage through IaC? The answer will vary from one organization to the next depending on factors like how frequently the processes happen and how they are conducted, of course.
But in general, there are three types of processes that are not good fits for IaC.
Operations that happen infrequently
The first is processes that take place on an infrequent basis – by which I mean once or twice a year at most.
There is an obvious and a less obvious reason why infrequent processes are poor candidates for IaC. The obvious one 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 the fact that the IaC templates you set up for infrequent processes may break over time due to changes in resources that the processes address. It is common for IaC to need maintenance due to shifting technology or enterprise policy. As a result, engineers may have to rework their code every time they use it – with the result that the total time and effort spent maintaining the IaC workflow outweigh the time and effort it saves.
For example, consider SSL certificate renewals. Most organizations maintain a relatively small number of SSL certificates, and those certificates usually expire once every year or two. It’s not hard to write IaC code that will automatically set up new certificates. But it’s also not particularly difficult or time-consuming to renew them manually – and if you write code to renew SSL certificates, there’s a fairly good chance that it won’t work a year or two from now because your certificate authority will have made changes to its renewal process.
Processes that depend on third-party resources
The second category of DevOps processes that most teams should not manage using IaC are ones that require deployment of third-party resources. These are poor candidates for IaC because 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. This is a process that is best handled manually.
Processes involving resources you can’t easily recreate
The final category of processes to avoid managing using IaC is those 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 secrets (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 period of time, there is 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.
Conclusion: Defining limits for IaC
Infrastructure-as-Code goes hand-in-hand with DevOps, and most teams should take advantage of IaC to streamline virtually everything they can. But the keyword there is virtually.
Some processes are just not good fits for 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.
To thrive at DevOps, recognizing when you should not use IaC is just as critical as taking advantage of this methodology wherever it makes sense.
