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 .

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 Infrastructureas-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

www . intelligentcio . com INTELLIGENTCIO NORTH AMERICA 75