Entrazure
What we build
Infrastructure as code, for the real estate. Terraform or Bicep covering what you actually run: networking, identity, data services, compute, monitoring. Existing hand-built resources are imported into state rather than rebuilt, so production keeps running while the code catches up with it.
Modules that are yours, not ours. A module layer sized to your patterns, with inputs named in your vocabulary and documentation written for the engineer joining in eighteen months. We do not ship a private module registry that only we can update.
Pipelines that plan on pull request and apply on merge. GitHub Actions or Azure DevOps. Every proposed change produces a plan visible in the pull request, so the reviewer sees what will happen before it happens. Applies run from the main branch only, with environment approvals where the blast radius justifies them.
Authentication without secrets. OIDC federated credentials between the pipeline and Entra ID workload identities. Nothing to rotate, nothing to store, nothing to find in an old build log. This alone closes the most common finding in an infrastructure security review.
Policy and drift as part of the pipeline. Azure Policy enforced at the management group level, plus checks in the pipeline that catch a non-compliant change before it is deployed rather than after. Drift is detected on a schedule and reported, because someone will eventually fix something in the portal at 2am and that is fine as long as the code finds out.
Application delivery, where it belongs. Build, test, container image, deployment to App Service, Container Apps or Azure Kubernetes Service, with environment promotion and a rollback that is one command rather than a rebuild. We size the platform to the team: a five-engineer team running a service mesh is a permanent operational tax.
Secrets and configuration. Managed identities wherever the service supports them, a key store for the rest, and configuration separated from code so promoting an artefact between environments does not mean rebuilding it.
Terraform or Bicep
This question consumes more meeting time than it deserves, so here is our position. Bicep is the right answer for an Azure-only estate with a Microsoft-centric team that does not want to operate remote state. Terraform is the right answer when you manage more than Azure, when you want the module ecosystem, or when your engineers already know it from a previous role.
What matters far more than the choice is whether anyone will maintain it. We build in the tool your team will still be using in three years, and we say so plainly if that is not the tool someone senior has already announced.
How the engagement runs
Week 1, assessment and decisions. What exists, what is deployed by hand, what the repository structure should be, which tool, which pipeline platform, and the environment and approval model. Output is a decision record with the reasoning attached.
Weeks 2 and 3, foundation and import. Repository, module structure, state configuration, OIDC credentials, and the first pipelines running end to end in a non-production environment. Existing resources begin to be imported.
Weeks 4 and 5, production and application pipelines. Promotion of the same code to production, branch protection, environment approvals, and the application build and release pipelines for one or two real services. Your engineers open their own pull requests from here on.
Week 6, drift, documentation and handover. Drift detection scheduled, policy checks wired into the pipeline, module documentation completed, and a working session covering the failure cases: a failed apply, a broken state lock, a rollback under pressure.
What you keep
- A Terraform or Bicep repository in your Git organization, with module documentation.
- Working pipelines with OIDC federated credentials and no stored secrets.
- The decision record from week one, including the options we rejected.
- Environment and approval configuration, already exercised on a real change.
- Drift detection with a defined owner for the report it produces.
- Runbooks for the three failures that actually happen: failed apply, state lock, emergency rollback.
- A backlog of what remains outside code, prioritized, with an estimate for each item.
Who this is for
Engineering and infrastructure teams of roughly three to thirty people who already have Azure workloads and are spending too much of the week on manual deployment, environment differences they cannot explain, or a release process that only one person can run. It pairs naturally with an Azure landing zone, which is itself delivered as code, and with a cloud migration, because a migration is the one moment where the whole estate passes through your hands.
Who this is not for
If you have three virtual machines and no plans to change them, the code will cost more to write than the clicking it replaces.
If your team has no capacity to review pull requests and no intention of acquiring it, you will end up with an infrastructure repository that drifts from reality within two quarters. That is worse than no repository, because people trust it. Say so at the start and we will scope managed Azure instead.
If a senior stakeholder has already mandated a tool for reasons nobody can articulate and the decision is not reopenable, we can still deliver, but the assessment week will surface the disagreement rather than paper over it.
Related
- Azure landing zone, the foundation these pipelines deploy.
- Cloud migration and VMware exit, where infrastructure as code pays for itself fastest.
- Compliance architecture, how pipeline evidence satisfies an auditor.
- All Azure services, the full engagement catalog.
Questions we get
Terraform or Bicep?
Bicep if you are Azure-only, your team is already Microsoft-centric and nobody wants to run state. Terraform if you have more than one cloud or SaaS provider to manage, or you want the module ecosystem. Both are defensible. We ask which one your team will still be maintaining in three years, and we build in that one.
We have existing resources built by hand. Do we start over?
No. We import the existing estate into state rather than redeploying it, which means production keeps running while the code catches up. Import is slower than a greenfield build and we scope it honestly: a few hundred resources typically takes two to three weeks of the engagement.
How do the pipelines authenticate to Azure?
OIDC federated credentials between your Git platform and Entra ID workload identities. No client secrets stored in a pipeline variable, nothing to rotate, nothing to leak in a log. If you have long-lived service principal secrets today, replacing them is usually the first security improvement we ship.
Do we need Kubernetes?
Probably not, and saying so costs us revenue. App Service or Container Apps handles most workloads with a fraction of the operational load. We recommend Azure Kubernetes Service when you have real multi-service orchestration, a portability requirement or a scaling profile that justifies it, and we design node pools and cost boundaries when we do.
Who reviews the pull requests once you leave?
Your engineers, which is why they are opening and reviewing pull requests from week three rather than watching us do it. If nobody on your side can review infrastructure changes, we say so during scoping and either train for it or propose a managed arrangement instead.
GitHub Actions or Azure DevOps?
Whichever you are already on. Both do this job properly. Migrating your source control platform in the middle of an infrastructure as code project adds risk to two things at once, and we would rather change one variable at a time.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.