AKS Delivery with Bicep and Terraform
One planned AKS application environment, implemented with Bicep and Azure DevOps or Terraform and GitHub Actions.
On this page
Bicep: GitHub → Azure DevOps Pipelines. Terraform: GitHub → GitHub Actions. Azure resources, identities, and configurations remain separate.
The problem and intended outcome
Deploying an application once is only part of the work. I want to make infrastructure changes reviewable, application releases repeatable, failures visible, and recovery explicit.
I plan to build one small containerized application on AKS, with images stored in Azure Container Registry. Two equivalent implementations will meet the same requirements and pass the same checks. This should make the differences between the toolchains observable rather than theoretical.
Two implementations, one set of requirements
| Area | Bicep + Azure DevOps | Terraform + GitHub Actions |
|---|---|---|
| Source code | Its own public GitHub repository | Its own public GitHub repository |
| Infrastructure | Bicep modules and environment parameters | Terraform modules and environment configuration |
| Delivery pipeline | Azure DevOps Pipelines | GitHub Actions |
| Change review | Validation and Bicep what-if | Validation and Terraform plan |
| State | Azure resource deployments; no Terraform state | Separate remote state and locking |
| Azure access | Federated service connection | Federated workflow identity |
| Application and checks | Same intended application and verification scenarios | Same intended application and verification scenarios |
The repositories will be independent. They will never manage the same live Azure resources. Resource names, resource groups, identities, and deployment configuration will distinguish implementation and target environment. Terraform state will belong only to the Terraform implementation.
DEV and TEST are configurable targets, not a requirement to keep two environments running. I intend to provision only what is needed for a verification session and clean it up afterwards.
Planned scope
- One small application, one container image, AKS, and Azure Container Registry.
- Infrastructure validation, change preview, and a controlled deployment step.
- Automated application tests, image build, publishing, deployment, and a smoke test.
- Federated pipeline authentication to Azure with scoped permissions.
- Kubernetes readiness and liveness probes, rolling updates, and a documented rollback procedure.
- Basic application logs, cluster/application metrics, and one alert for a useful failure signal.
- Cleanup instructions, resource inventory, and cost observations.
This first version will not attempt a multi-region platform or a full enterprise landing zone. The focus is a small system whose delivery and recovery can be explained and reproduced.
Planned verification scenarios
These are acceptance criteria, not completed results. Both implementations will use the same application behavior, release scenario, and expected outcomes.
| Scenario | Evidence to capture |
|---|---|
| Validate and preview infrastructure | Validation output and reviewed change preview before deployment |
| Deploy the application | Pipeline run, ready Pods, and a successful smoke test |
| Update the application | A new image version and a completed rollout with the expected response |
| Introduce a broken release | A controlled failure, its detection, and a recorded decision to recover |
| Recover explicitly | Execution of the rollback procedure and a passing smoke test afterwards |
| Observe the failure | Relevant logs and metrics, plus the alert triggered by the chosen failure signal |
| Clean up | Resource inventory before and after removal, including retained resources and state |
Rolling updates do not automatically guarantee zero downtime. Recovery will be an explicit procedure; this plan does not assume automatic rollback. The failure exercise will be limited to the disposable lab environment.
What the comparison should reveal
I will compare how each implementation handles change review, environment configuration, authentication, failed releases, and cleanup. Any conclusions about effort, reliability, or cost will be based on recorded implementation evidence. Neither toolchain is presented as a winner in advance.