Professional & digital services · IaC standardisation
Turning manually created Azure environments into reusable delivery products
A modular Infrastructure-as-Code framework for networking, compute, storage, monitoring, access, tagging and controlled deployment.
12
environments standardised
1 hour
provisioning (from 4 days)
81%
less configuration drift
88%
fewer manual steps
In brief
A services organisation created Azure environments independently per application and project, with varied naming, networking, access, monitoring and deployment. ClimsTech built a modular Terraform framework, retained useful ARM templates, introduced remote state and pull-request review, and standardised tagging and ownership — standardising stable decisions while preserving controlled flexibility.
Working constraints
- Existing Azure estates
- Multiple project teams
- Different application requirements
- Existing ARM templates
- Need for gradual adoption
- Remote state and access considerations
- Requirement to avoid one oversized template
The problem
What was actually going wrong
A services organisation created Azure environments independently for different applications and customer projects. Naming, network configuration, access control, monitoring, and deployment practices varied.
What discovery surfaced
- 1Environment creation depended on senior engineers.
- 2Portal changes were not consistently reviewed.
- 3Resource naming and tagging varied.
- 4Test and production environments drifted.
- 5Existing ARM assets still had value.
- 6Infrastructure modules were too application-specific or absent.
The engineering
What we built and changed
1Pattern discovery
Existing environments were compared to identify stable common components.
2Module design
Networking, compute, storage, monitoring, access, and application foundations were separated into distinct modules.
3State and workflow
Remote state, pull-request review, and deployment approval were implemented.
4ARM integration
Existing useful ARM templates were retained where rewriting added no value.
5Governance
Naming, tagging, ownership, and environment metadata were standardised across all environments.
Infrastructure became a reviewed, reusable product instead of a collection of one-off environments.
The architecture
Before and after
- Manually created Azure environments
- Ad-hoc ARM templates per project
- Portal changes without review
- Inconsistent naming and tagging
- Senior engineer dependency
- No remote state
- Environment configuration
- Networking module
- Compute module
- Storage module
- Monitoring module
- Access-control module
- Application-specific components
Judgement calls
Decisions that shaped the outcome
Why avoid a single universal module?
Large modules become difficult to understand and change. Stable capabilities were separated by responsibility.
Why preserve selected ARM templates?
Standardisation should reduce operational risk, not create unnecessary migration work.
Why separate configuration from modules?
Reusable modules need environment-specific input without code duplication.
Verified outcomes
What changed for the business
- 12 environments standardised
- Provisioning reduced from 4 days to 1 hour
- Drift reduced by 81%
- Manual steps reduced by 88%
- Tagging compliance increased from 42% to 96%
- Infrastructure support requests reduced by 38%
- New-project setup effort reduced by 70%
What this engagement proves
The best IaC frameworks standardise stable decisions while preserving controlled flexibility.
Field notes on this class of problem
All field notesManaging Terraform state without fear
Treat state as critical infrastructure: backends, locking, segmentation, drift.
22 min read
DevOps & deliveryInfrastructure as Code at scale: from a Terraform monolith to modules
Decompose the one giant Terraform state before a bad apply touches everything.
19 min read
DevOps & deliveryGitOps in practice: your cluster should match your git history
Git as the source of truth, the cluster reconciling to it — and where that breaks.
19 min read