Problem statement: There is a growing need for dynamic, reliable and repeatable infrastructure as the scope expands to small footprint to deployments to cloud scale. Some of the manual approaches and management practices cannot keep up. There are two popular ways to meet these demands on the Azure public cloud which are Terraform and ARM templates. This article compares these two frameworks and their use cases. Specifically, we include a use case for DevSecOps and its applicability to the development and operation of trustworthy infrastructure-as-a-code.

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.

Azure Blueprints can be leveraged to allow an engineer or architect to sketch a project’s design parameters, define a repeatable set of resources that implements and adheres to an organization’s standards, patterns and requirements.  It is a declarative way to orchestrate the deployment of various resource templates and other artifacts such as role assignments, policy assignments, ARM templates, and Resource Groups. Blueprint Objects are stored in the CosmosDB and replicated to multiple Azure regions. Since it is designed to setup the environment, it is different from resource provisioning. This package fits nicely into a CI/CD.

With Azure templates, one or more Azure resources can be described with a document, but it doesn’t exist natively in Azure and must be stored locally or in source control. Once those resources deploy, there is no active connection or relationship to the template.

Other IaC providers like Terraform also have features such that it tracks the state of the real-world resources which makes Day-2 and onward operations easier and more powerful and with Azure Blueprints, the relationship between what should be deployed and what was deployed is preserved. This connection supports improved tracking and auditing of deployments. It even works across several subscriptions with the same blueprint.

Typically, the choice is not between a blueprint and a resource template because one comprises the other but between an Azure Blueprint and a Terraform tfstate. They differ in their organization methodology as top-down or bottom-up. Blueprints are great candidates for compliance and regulations while Terraform is preferred by developers for their flexibility. Blueprints manage Azure resources only while Terraform can work with various resource providers.

Once the choice is made, some challenges will require to be tackled next. The account with which the IaC is deployed and the secrets it must know for those deployments to occur correctly are something that works centrally and not in the hands of individual end-users. Packaging and distributing solutions for end-users is easier when these can be read from a single source of truth in the cloud, so at least the location in the cloud for the solution to read and deploy the infrastructure must be known beforehand.

The DevSecOps workflow has a double loop between various stages including create->plan->monitor->configure->Release->Package->Verify where the create, plan, verify and package stages belong to Dev or design time and the monitor, configure and release belong to operations runtime. SecOps sits at the cusp between these two halves of Dev and Ops and participates in the planning, package and release stages.

Some of the greatest challenges of DevSecOps are firstly, cultural in that it comes from market fragmentation in terms of IaC providers and secondly, variety of wide skills required for such IaC. Others include definition of well-known code or design patterns, difficulty in replicating errors, IaC language specifics and diverse toolset, security and trustworthiness, configuration drift and changing infrastructure requirements.