Platform engineering on Microsoft Azure

Every API, one thread.
From intake to incident.

We build API platforms on Azure where deploying is the release, the record writes itself, and a single console answers every question with evidence rather than guesswork.

See the platform Start a conversation
  • Landing zone, gateway, edge and identity as code
  • Per-API promotion through dev, QA and production
  • Diagnosis by correlation id across the whole request path
Edge, Gateway, Identity and Foundation at the corners; the Console at the centre reads all four. Edge Gateway Identity Foundation Console
Four corners hold the facts. The centre reads them all.
15 mindrift monitor across every environment
17readiness checks before an API is admitted
dev → qa → prodpromotion per API, with a human gate on production
0changes made in the Azure portal

The platform

Four corners and a centre

An API reaches production through systems that do not know about each other. We treat each one as a corner that holds a piece of the truth, and put one console in the middle that reads all of them.

Edge

Front Door, custom domains, managed certificates and WAF policies defined in one configuration and deployed by pipeline. New origins are onboarded with zero touch: scaffold, pull request, Private Link approval, CNAME, certificate.

  • Front Door
  • WAF
  • Private Link

Gateway

API Management as the single source of truth for every definition, policy and named value. Each build is fingerprinted and pinned as an immutable tag; each environment keeps its own ledger branch. The gateway is checked after every promotion.

  • API Management
  • APIOps
  • Contract parity

Identity

Which applications may talk to which, as code. One registry entry creates the Entra app registrations, roles, scopes and service principals for every environment. Secrets rotate daily into Key Vault; anything not in the registry is removed.

  • Entra ID
  • Key Vault
  • Grants as code

Foundation

A landing zone in Bicep: virtual network, private subnets, NAT, private DNS, Log Analytics, App Service and API Management, all private. The naming standard is code, so nobody types a resource name. App repositories build an image and nothing else.

  • Bicep
  • Private networking
  • Module registry

Console

The one point that reads all four. Where is this API running, what changed, who approved it, who calls it, and why did this request fail. Nothing is typed in; everything is derived from the systems of record. The same answers are available to engineers in the UI and to Copilot, Claude and Cursor through MCP tools.

  • Change ledger
  • Readiness gate
  • Diagnosis engine
  • MCP

The lifecycle

One thread per API, left to right

The console's navigation is the lifecycle itself. Each stage has one question, and each answer comes from evidence.

  1. 01

    Onboard

    One form. The console opens the security pull request, runs the identity pipeline, registers the API and performs the first promotion, reporting each step.

  2. 02

    Verify

    Per environment: does the app registration exist, does the gateway identity hold its role, does the backend serve its contract. Ready, Blocked or Unknown, with the fix named.

  3. 03

    Release

    A finished deploy stage promotes that API only. Tags, branches, pull requests and runs become a change ledger: what, when, how, who, and the evidence.

  4. 04

    Operate

    Live request flow, per-operation traffic and callers, service levels and error budgets. A monitor checks the gateway still matches each backend and posts to Teams on drift.

  5. 05

    Resolve

    Paste a correlation id. The engine walks edge, WAF, gateway and backend and returns a verdict with evidence. Roll back opens the promote pipeline pre-filled with the previous tag.

  6. 06

    Improve

    A delivery scorecard, a conformance score per API per environment, a weekly brief, and lessons kept from every diagnosis.

How we work

Rules the platform is built on

“Deploying is the release.”

Promotion is a side effect of a team's own pipeline, per API. There is no coordinated release train.

“Azure is never changed in the portal.”

Configuration files are the single source of truth. Pipelines make Azure match them exactly, and drift is removed rather than tolerated.

“Reads are live. Writes are pull requests.”

The console holds no write rights on identity, the gateway or main branches. Every change leaves a reviewable trail.

“Evidence or a gap, never a guess.”

Unknown is shown in amber and says what would make it known. Nothing on screen is inferred.

“One action per problem.”

Every red row has exactly one button, and it opens the thing that fixes it, already filled in.

“No manual lists of APIs.”

Identity is derived from naming conventions. The record falls out of shipping; nobody maintains a spreadsheet.

About

Built by an engineer who runs it

Azure Software Engineer is led by Conor O'Sullivan. The platform described here is not a slide deck: it runs as a working estate on Azure, with its landing zone, gateway, edge, identity and console all deployed from code and checked by pipeline.

The approach is deliberately plain. No tuned model, no vector database, no graph database and no data warehouse. Git, pipelines, tags and the Azure control plane already hold the facts; the work is in making them answer questions.

  • Landing zonesBicep, private by default, naming as code
  • API operationsContract parity, immutable tags, gateway checks
  • Edge operationsFront Door and WAF as configuration
  • Identity as codeEntra registrations, grants and rotation
  • DiagnosticsCorrelation-id walks, drift detection, incident sweeps
  • Agent accessMCP tools that give the same answers as the UI

Contact

Talk to us about your API estate

Whether you are standing up a landing zone, bringing API Management under control, or trying to shorten the hours spent stitching logs together, start with an email.

conor@azuresoftwareengineer.com