t cht lk establishes the connection , you can ’ t write code to provision this type of resource automatically . This is a process that is best handled manually .
t cht lk establishes the connection , you can ’ t write code to provision this type of resource automatically . This is a process that is best handled manually .
3 . 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 IaCbased 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 . p
www . intelligentcio . com INTELLIGENTCIO LATAM 65