Platform Engineering for .NET & Azure Teams

Platform Engineering represents the discipline of designing and building internal developer platforms (IDPs) that enable development teams to deliver software faster and with less cognitive load. Rather than forcing developers to manage infrastructure complexity directly, platform engineering teams create self-service capabilities, golden paths, and automated workflows that abstract away operational concerns.

At its core, platform engineering focuses on treating the platform as a product with developers as customers. This means understanding developer needs, measuring platform adoption, and continuously improving the developer experience (DevEx). The goal is to reduce toil, standardize best practices, and enable teams to focus on business logic rather than infrastructure configuration.

Key Focus Areas

Self-Service Infrastructure: Providing developers with on-demand access to environments, services, and resources through APIs, portals, or CLI tools. This includes provisioning databases, deploying applications, configuring observability, and managing secrets—all without requiring manual operations team intervention.

Golden Paths: Establishing opinionated, well-paved workflows that guide developers toward secure, compliant, and efficient patterns. Golden paths reduce decision fatigue and ensure consistency across teams while still allowing flexibility when needed.

Developer Experience (DevEx): Optimizing tooling, documentation, and workflows to minimize friction in the development lifecycle. This includes reducing build times, simplifying deployment processes, and providing clear feedback loops.

Platform Engineering intersects with DevOps, Infrastructure as Code, Kubernetes, CI/CD, and Cloud Native practices. It also draws heavily on Automation principles and increasingly leverages GitOps methodologies.

Platform Engineering Without Backstage: Pragmatic IDPs on Azure

Platform Engineering Without Backstage: Pragmatic IDPs on Azure

Every platform engineering conference talk in the last two years has had a Backstage slide. Glossy catalogue screenshot, a scaffolder demo that creates a repo in four clicks, a knowing nod about “developer experience”. What the slide never shows is the six months the team spent building plugins, the Postgres instance somebody now babysits, the TechDocs theme nobody asked for, and the 0.4 of an engineer permanently assigned to chasing Backstage’s two-week release cadence.

There is no shame in any of this. Backstage is a serious project and serious teams run it well. The shame is treating it as the default (the thing you reach for on day one) when most teams could ship 80% of the value with a tenth of the effort and a fraction of the running cost. Backstage is a platform for building platforms. Most teams need a platform, not a platform-platform.

This post is the Internal Developer Platform (IDP) I keep building when nobody is forcing me to use Backstage. It is small, opinionated, runs on Azure plumbing you already pay for, and ships value in the first quarter instead of the third year.

Storage Architecture & Stateful Workloads in AKS

Storage Architecture & Stateful Workloads in AKS

Stateful workloads in Kubernetes require understanding PersistentVolume architecture, Azure storage trade-offs, and backup strategies. This article covers PVC/PV patterns, Azure Disk vs Files performance profiles, Velero backup configurations, and multi-cluster replication patterns based on production experience.
AKS Architecture & Operations — The Complete Series

AKS Architecture & Operations — The Complete Series

AKS documentation gets you to a running cluster. It does not tell you which storage class destroys your stateful workload during a node pool replacement, why your 300-node upgrade caused cascading evictions when the 50-node one was fine, or where Workload Identity Federation fails silently in production. This series covers nine architectural domains — identity, storage, cost, networking, upgrades, registry security, disaster recovery, hybrid operations, and scale — with the specificity that matters when something breaks at 2 AM.
Kubernetes Is Not a Platform Strategy

Kubernetes Is Not a Platform Strategy

Kubernetes has become an assumed default in many organizations, positioned as a universal platform that absorbs governance, security, observability, and operational responsibility. This narrative is incomplete. Kubernetes is a powerful runtime orchestrator that solves one phase of the software lifecycle. Architectural risk, cost decisions, and operational failure occur elsewhere. A critical examination of where Kubernetes’s responsibility ends, and what remains the architect’s job.
AKS Network Policies: The Security Layer Your Cluster Is Missing

AKS Network Policies: The Security Layer Your Cluster Is Missing

Network segmentation is a fundamental security control for modern Kubernetes environments. AKS supports multiple networking models such as kubenet, Azure CNI, and overlay CNIs. The networking model matters, but the decisive factor for enforcing isolation and compliance is the consistent application of network policies.

This article describes how network policies work in AKS, the available engines, practical examples, and recommended practices for enforcing a zero-trust posture within a cluster.