How to address IaC shortcomings – Part 2?

A previous article discussed a resolution to IaC shortcomings for declaring dependencies between resources for deployment to public cloud. This article discusses another case where the IaC does not yet fully capture the configurations possible for a resource.

As a recap, almost all IaC providers try to keep pace with the new features being added to a resource type and while the format of the template can vary between say Azure Resource Manager and Terraform, the IaC provider is usually the resource provider as well.  Terraform is universally extendable through providers that furnish IaC for resource types. It’s a one-stop shop for any infrastructure, service, and application configuration. It can handle complex order-of-operations and composability of individual resources and encapsulated models. It is also backed by an open-source community for many providers and their modules with public documentation and examples. Microsoft also works directly with the Terraform maker on building and maintaining related providers and this partnership has gained widespread acceptance and usage. Perhaps, one of the best features is that it tracks the state of the real-world resources which makes Day-2 and onward operations easier and more powerful.

ARM templates are entirely from Microsoft consumed internally and externally as the de facto standard for describing resources on Azure and with their import and export options. There is a dedicated cloud service called the Azure Resource Manager service that expects and enforces this convention for all resources to provide effective validation, idempotency and repeatability.

Some features including the sought-after preview features are delayed from inclusion in the templates until General Acceptance, but they should still be available from the ARM template. In such cases, leveraging mixed templates in the IaC source helps to bridge the gap between what can be defined in the IaC and what can be made available from the public cloud. We strive to reduce the drift between the public cloud and the IaC.

The folder structure will separate the Terraform templates into a folder called ‘module’ and the ARM Templates will be located in another folder at the same level and named something like ‘subscription-deployments’ and include native blueprints and templates. The GitHub workflow definitions will leverage proper handling of either location or trigger the workflow on any changes to either of these locations.

Finally, PowerShell scripts can help with both the deployment as well as the pipeline automations. There are a few caveats with scripts because the general preference is for declarative and idempotent IaC rather than script whether those attributes are harder to enforce, and the logic quickly expands to cover a lot more than originally anticipated. All scripts can be stored in folders with names ending with ‘scripts’.

It is preferable not to save state in the IaC source code repository and if necessary, it can be stored in the public cloud itself.

These are sufficient to address the above-mentioned shortcomings in the Infrastructure-as-Code.