Microsoft Azure for DevOps #

Azure is a strong fit for organizations that need enterprise identity integration, policy-driven governance, and flexible platform choices from PaaS to Kubernetes.

Kubernetes path #

Planning managed Kubernetes on AKS? Start with the Kubernetes Deep Dive: Minikube to AKS/EKS to practice cluster workflows before production design, then compare platforms in EKS vs AKS vs GKE.

Overview #

Typical Azure DevOps stacks combine:

  • Identity and access with Microsoft Entra ID and Azure RBAC.
  • Governance with management groups, policies, and landing zones.
  • Delivery automation with Azure DevOps Pipelines or GitHub Actions.
  • Operations with Azure Monitor, Log Analytics, and Application Insights.

When to choose this provider #

Choose Azure when you need:

  • Tight integration with Microsoft enterprise identity and tooling.
  • Strong governance with policy and management-group hierarchy.
  • Managed application platforms including AKS and App Service.
  • A strong fit for Windows, .NET, Microsoft 365, and hybrid enterprise estates.

When not to choose this provider #

Azure may not be the best first choice when:

  • Your team has little Microsoft operational experience and wants a minimal cloud surface.
  • You cannot design subscription, policy, RBAC, and networking boundaries early.
  • Your platform is primarily Linux/Kubernetes-focused and does not need Microsoft integrations.
  • You need niche managed services that are stronger in another provider ecosystem.

Baseline DevOps architecture #

A practical Azure baseline includes:

  • Management groups and subscriptions split by environment, workload criticality, and ownership.
  • Microsoft Entra ID federation, Azure RBAC, and policy initiatives for core guardrails.
  • Hub-and-spoke or equivalent networking with centralized firewall, DNS, and private endpoints.
  • CI/CD through Azure DevOps Pipelines or GitHub Actions using managed identity where possible.
  • Azure Monitor, Log Analytics, dashboards, and production alert rules tied to runbooks.

Architecture patterns #

1) Landing zone by management group #

  • Separate production and non-production subscriptions.
  • Apply baseline policy initiatives at management group level.
  • Centralize shared networking, logging, and security tooling.

2) AKS platform pattern #

  • Separate clusters by environment and risk profile.
  • Integrate workload identities for pod/service authentication.
  • Standardize ingress, policy admission, and observability add-ons.

3) App Service pattern #

  • Use deployment slots for safe rollouts.
  • Automate infra + app deployment in single pipeline.
  • Use managed identity for service-to-service access.

Security checklist #

  • Enforce MFA and conditional access for privileged users.
  • Use managed identities instead of stored secrets when possible.
  • Keep secrets and certificates in Azure Key Vault.
  • Enable centralized audit and platform logging.

Cost-control checklist #

  • Tag resources for ownership and cost center tracking.
  • Set budgets and alerts at subscription/resource group levels.
  • Use autoscale and right-sizing recommendations.
  • Regularly review idle resources and reserved capacity options.

Implementation examples #

Example Bicep policy bootstrap snippet # 

param location string = resourceGroup().location

resource logAnalytics "Microsoft.OperationalInsights/workspaces@2022-10-01" = {
  name: "law-platform-${uniqueString(resourceGroup().id)}"
  location: location
  properties: {
    sku: { name: "PerGB2018" }
    retentionInDays: 30
  }
}

resource storageHttpsOnly "Microsoft.Authorization/policyAssignments@2022-06-01" = {
  name: "require-https-storage"
  properties: {
    policyDefinitionId: "/providers/Microsoft.Authorization/policyDefinitions/2a1a9cdf-e04d-429a-8416-3bfb72a1b26f"
    displayName: "Require secure transfer for Storage Accounts"
  }
}

Example CI/CD flow #

  1. Pull request validation with unit tests and security checks.
  2. Build and publish artifact/container.
  3. Deploy to test environment and run smoke tests.
  4. Promote to production using approvals and rollout strategy.
  5. Track deployment health with monitor alerts and dashboards.

Example Terraform baseline #

  • Subscription-level role assignments and policy sets.
  • Network baseline modules (hub/spoke or equivalent).
  • Log Analytics workspace and standard alert rules.

Migration/adoption path #

  1. Create management groups and baseline policy initiatives first.
  2. Roll out hub-and-spoke networking and central observability before app migrations.
  3. Move CI/CD to workload identities and Key Vault-backed secret retrieval.
  4. Migrate low-risk applications to AKS/App Service, then expand to regulated workloads.
  5. Add policy exemptions with expiry dates to prevent permanent governance drift.

Pitfalls / anti-patterns #

  • Flat subscription model without governance boundaries.
  • Secrets embedded in pipeline variables without rotation.
  • Manual environment drift from click-ops changes.
  • Missing ownership tags and spending controls.

References #