Azure: Platform Engineering

Platform engineering has moved from buzzword to business imperative. The goal is simple: reduce cognitive load for development teams while maintaining the governance that enterprises require. Azure offers multiple paths to this destination—choosing the right one depends on where your organization sits on the maturity curve.

The Platform Engineering Mindset

Platform engineering isn't about building another layer of infrastructure for developers to navigate. It's about creating "golden paths"—opinionated, well-lit routes that make doing the right thing the easy thing. Teams can deviate when they need to, but the default path handles 80% of use cases with minimal friction.

This represents a shift from the early DevOps era, where we expected every team to become infrastructure experts. That approach created bottlenecks, inconsistency, and a lot of YAML files that nobody fully understood. Platform engineering acknowledges that developers want to ship features, not debug Kubernetes networking.

Azure Compute Options: Choosing Your Foundation

Azure provides multiple compute options, each with different tradeoffs between control and convenience. The right choice depends on your workload characteristics, team skills, and organizational constraints.

The Decision Framework

Internal Developer Platform Architecture

An Internal Developer Platform (IDP) abstracts infrastructure complexity behind self-service interfaces. Developers interact with the platform through templates, CLIs, and portals—not directly with Azure resources.

Key Components

Service Catalog: A curated list of approved services, templates, and integrations. Developers browse the catalog to find pre-approved building blocks rather than figuring out which Azure services to use.

Self-Service Portal: A UI (often built with Backstage, Port, or custom tooling) where developers request resources, view their applications, and access documentation. The portal abstracts the underlying Azure complexity.

GitOps Pipeline: Infrastructure and application changes flow through Git. Pull requests trigger policy checks, and merges trigger deployments. This creates an audit trail and enables rollback.

Golden Paths in Practice

Abstract concepts become concrete through golden paths. Here's an example of what a golden path looks like for deploying a new microservice:

Implementing with Azure DevOps and GitHub

Both Azure DevOps and GitHub Actions work well for platform engineering. The choice often comes down to existing investments and specific feature requirements.

name: Deploy to Container Apps

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      
      - name: Azure Login (OIDC)
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      
      - name: Deploy Container App
        uses: azure/container-apps-deploy-action@v1
        with:
          containerAppName: myapp
          resourceGroup: rg-platform-prod
          imageToDeploy: myacr.azurecr.io/myapp:${{ github.sha }}

Observability as a Platform Service

Application teams shouldn't configure monitoring from scratch. The platform provides observability as a service—applications inherit dashboards, alerts, and log queries automatically.

The Observability Stack

• Azure Monitor: Centralized metrics and logs across all workloads
• Application Insights: APM with distributed tracing (auto-instrumentation where possible)
• Log Analytics: Centralized workspace with standardized queries
• Grafana (Azure Managed): Unified dashboards across Azure and non-Azure sources
• Alerts: Pre-configured alert rules for golden signals (latency, traffic, errors, saturation)

The platform team maintains base dashboards and alert templates. Application teams can customize, but they start with sensible defaults that cover 80% of monitoring needs.

Measuring Platform Success

Platform engineering is an investment. You need metrics to demonstrate value and identify improvement areas.

Getting Started

Platform engineering is a journey, not a destination. Start small, prove value, and expand:

1. Pick one workload type—containerized APIs are a good starting point
2. Build the golden path—template, pipeline, monitoring, documentation
3. Onboard pilot teams—get feedback, iterate
4. Measure and communicate—show time savings, security improvements
5. Expand the catalog—add more workload types, more self-service capabilities

The goal isn't perfection—it's continuous improvement in developer productivity while maintaining the governance that your organization requires.