t cht lk as code save time and reduce toil for engineers but it also increases consistency and minimizes the risk of errors triggered by human oversight .
t cht lk 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 .
1 . 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 . 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 .
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 .
2 . 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 thirdparty resources are beyond your control .
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
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
64 INTELLIGENTCIO LATAM www . intelligentcio . com