This is a continuation of previous articles on IaC shortcomings and resolutions. 

As with all automation, it is important to register them in source control so that their maintenance can become easy. It is also important to secure the credentials with which these scripts run. Finally, lockdown of all resources in terms of network access and private planes is just as important as their accessibility for automation.  

Many organizations don’t invest in Azure DevOps  for a variety of reasons, with attachments to on-premises based automation technology or avoiding public cloud automations for misplaced cost concerns. Other reasons can be genuine though. For example, one of the most common tasks is to download and run an executable instead of calling an API. This is convenient for portability and the same executable can be run using various Azure accounts or subscriptions. But if we take an automation account or runbook, then the downloaded executable might not run because the execution policy cannot be changed. The same goes for hybrid worker and the only way to overcome the limitation is to spin up a dedicated compute and modify it  to allow execution. It might be noteworthy to add that compute instance or cluster created on a databricks workspace or Azure machine learning workspace might also not work.  Their pass-through active directory authentication works only for notebooks but not the shell on the compute. This kind of limitation extends to other data oriented automations because they in turn leverage the workspaces and do not allow any activity on the scripts or notebooks that these workspaces cannot run.

Such a limitation, on the other hand, does not hold on the GitOps which has been one of the favorites for code delivery pipelines. In the GitOps, it is not only easy to download the executable from say an object repository such as Artifactory but also easy to pass command line parameters whose values are already known to the pipeline. Organizing the automation in GitOps is also fairly straightforward as pipelines become scoped to the code they push. 

Finally, there is a lot of maintenance work required  with scripts and automations and the use of source control becomes inevitable. Keeping the automations and the code they service as repositories enable them to be shared as appropriate.

These are some of the examples where a cloud native approach might not be straight. When organizations do enable Azure DevOps, they enhance their capabilities which gives them a  more secure, manageable and futuristic platform albeit one that dictates rewriting or rehosting the legacy scripts.