Sep 6, 2025

Infrastructure as Code (Bicep/ARM vs. Terraform/CloudFormation)

Mind Map Summary

Infrastructure as Code (IaC)
- What: Managing and provisioning infrastructure (networks, VMs, databases) using code and automation, rather than manual processes.
- Core Benefits:
  - Consistency & Repeatability: Eliminates configuration drift and human error.
  - Version Control: Infrastructure definitions are stored in Git, enabling change tracking, rollbacks, and collaboration.
  - Automation: Integrates with CI/CD pipelines for automated deployments.
  - Documentation: The code itself serves as living documentation of your infrastructure.
IaC Tools
- Cloud-Native (Platform-Specific)
  - AWS CloudFormation: AWS’s native IaC. Uses JSON/YAML. Deeply integrated with AWS services.
  - Azure Resource Manager (ARM) Templates: Azure’s native IaC. Uses JSON. Can be verbose.
  - Azure Bicep: A Domain-Specific Language (DSL) for Azure. More concise and readable than ARM, compiles to ARM JSON.
- Cloud-Agnostic (Multi-Cloud)
  - Terraform (HashiCorp): The most popular multi-cloud IaC tool.
  - Language: HashiCorp Configuration Language (HCL).
  - Pros: Can manage infrastructure across virtually any cloud provider (AWS, Azure, GCP, etc.) and on-premise systems with a single tool and language. Large community and ecosystem.
  - Cons: Requires managing state files. May lag slightly behind cloud providers in supporting brand new services.

Core Concepts

1. The Problem IaC Solves

Traditionally, infrastructure was provisioned manually through cloud provider consoles or scripts. This led to inconsistencies between environments (dev, staging, prod), human error, and difficulty in tracking changes. IaC treats infrastructure like application code. You define your desired infrastructure in configuration files, which are then version-controlled and deployed automatically. This ensures that every environment is identical and can be recreated reliably.

2. Cloud-Native IaC Tools

AWS CloudFormation: AWS’s declarative language for describing your entire AWS infrastructure. You define resources like EC2 instances, S3 buckets, and RDS databases in a JSON or YAML template. CloudFormation then provisions and configures these resources as a single unit (a “stack”).
Azure ARM Templates: Similar to CloudFormation, ARM templates are JSON files that define the resources you want to deploy to Azure. They are the native deployment language for Azure. While powerful, their JSON syntax can be very verbose and complex, especially for large deployments.
Azure Bicep: Bicep is a significant improvement over raw ARM templates. It’s a more human-readable and concise language that compiles directly into ARM JSON. It offers better syntax, modularity, and type safety, making it the recommended way to deploy infrastructure to Azure.

3. Cloud-Agnostic IaC Tools

Terraform: Terraform is a widely adopted open-source IaC tool that allows you to define and provision infrastructure across multiple cloud providers and on-premise environments. Its key strength is its provider model, which allows it to interact with almost any API. Terraform maintains a “state file” that maps your configuration to the real-world resources, enabling it to intelligently plan and apply changes.

Practice Exercise

Write an IaC template (using your choice of Bicep or Terraform) to deploy a simple web application. The template should provision a compute resource (App Service or EC2) and a database.

Answer

I will provide an example using Azure Bicep as it’s concise and demonstrates the benefits of a modern cloud-native IaC language.

1. Azure Bicep Template (`main.bicep`)

This template will deploy:

An Azure App Service Plan (the hosting environment)
An Azure App Service (the web application itself)
A SQL Server logical server
An Azure SQL Database

// Parameters for customization
param location string = resourceGroup().location
param appServicePlanName string = 'appserviceplan-${uniqueString(resourceGroup().id)}'
param webAppName string = 'webapp-${uniqueString(resourceGroup().id)}'
param sqlServerName string = 'sqlserver-${uniqueString(resourceGroup().id)}'
param sqlDatabaseName string = 'sqldb-${uniqueString(resourceGroup().id)}'
param sqlAdminLogin string = 'sqladmin'
param sqlAdminPassword string = newGuid() // Generate a new strong password

// App Service Plan
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: appServicePlanName
  location: location
  sku: {
    name: 'B1' // Basic tier
    tier: 'Basic'
    capacity: 1
  }
  properties: {
    reserved: true
  }
}

// Web App
resource webApp 'Microsoft.Web/sites@2022-03-01' = {
  name: webAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
    siteConfig: {
      appSettings: [
        {
          name: 'ASPNETCORE_ENVIRONMENT'
          value: 'Production'
        }
        {
          name: 'ConnectionStrings:DefaultConnection'
          value: sqlDatabase.properties.fullyQualifiedDomainName // Reference the SQL DB output
        }
      ]
      linuxFxVersion: 'DOTNETCORE|8.0' // Example for .NET 8 on Linux
    }
  }
}

// SQL Server
resource sqlServer 'Microsoft.Sql/servers@2022-05-01-preview' = {
  name: sqlServerName
  location: location
  properties: {
    administratorLogin: sqlAdminLogin
    administratorLoginPassword: sqlAdminPassword
    version: '12.0' // SQL Server 2019
  }
}

// SQL Database
resource sqlDatabase 'Microsoft.Sql/servers/databases@2022-05-01-preview' = {
  parent: sqlServer
  name: sqlDatabaseName
  location: location
  sku: {
    name: 'Basic'
    tier: 'Basic'
  }
  properties: {
    collation: 'SQL_Latin1_General_CP1_CI_AS'
    maxSizeBytes: 2147483648 // 2 GB
  }
}

// Output the web app URL and SQL connection string
output webAppUrl string = webApp.properties.defaultHostName
output sqlConnectionString string = 'Server=tcp:${sqlServer.properties.fullyQualifiedDomainName},1433;Initial Catalog=${sqlDatabase.name};Persist Security Info=False;User ID=${sqlAdminLogin};Password=${sqlAdminPassword};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;'

Explanation

Parameters: The template starts by defining parameters, allowing you to customize the deployment (e.g., location, resource names). uniqueString(resourceGroup().id) is used to generate unique names to avoid conflicts.
Resource Definitions: Each resource block defines an Azure resource. Bicep uses a declarative syntax where you specify the desired state of the resource.
- appServicePlan: Defines the underlying compute plan for the web app.
- webApp: Defines the web application itself, linking it to the appServicePlan and setting an environment variable for the connection string.
- sqlServer: Defines the logical SQL Server instance.
- sqlDatabase: Defines the database within the SQL Server. Notice the parent: sqlServer property, which establishes a clear parent-child relationship.
Dependencies: Bicep automatically understands dependencies. For example, the webApp depends on the appServicePlan, and the sqlDatabase depends on the sqlServer. Bicep ensures these resources are created in the correct order.
Outputs: The output statements define values that will be returned after the deployment, such as the web app’s URL and the full SQL connection string.

How to Deploy (using Azure CLI)

Install Bicep CLI: az bicep install
Deploy: az deployment group create --resource-group <your-resource-group> --template-file main.bicep --parameters location=<your-location>

This single Bicep file allows you to reliably deploy a complete web application infrastructure to Azure with a single command, ensuring consistency and repeatability.