Cloud Native Development with .NET & Azure

Cloud-native is the part of a system that survives a node restart, a region failover, and a container image swap without anyone logging into a server. The label gets attached to a lot of architectures that fail at least one of those tests. The articles here treat cloud-native less as a marketing category and more as a set of properties — declarative configuration, externalized state, replaceable instances, observable behavior — that a .NET workload either has or does not have.

Containerization content focuses on what changes when an ASP.NET Core app stops owning its filesystem. Multi-stage Dockerfiles for trim-compatible builds, distroless base images, the difference between dotnet publish output that runs in a sidecar and output that survives a privileged-pod constraint. Image size matters less than image surface area, and most .NET base images ship more than the workload needs.

Twelve-factor adaptation for .NET gets concrete treatment. Configuration via environment variables and Key Vault references rather than appsettings.{Environment}.json. Logging to stdout in a structured format instead of rolling files on a host nobody can SSH into. Graceful shutdown via IHostApplicationLifetime rather than a Windows-service-era assumption that the process gets a clean exit. Each of these is a small change and a load-bearing one.

Observability for cloud-native .NET goes through OpenTelemetry: traces that survive the gateway hop, metrics emitted from System.Diagnostics.Metrics instead of legacy counters, logs correlated by W3C trace context instead of a custom Activity.Current workaround. The articles cover the SDK wiring and the platform-side configuration that has to match for any of it to produce usable signal.

Service-to-service patterns — health checks that report actual dependency state, retry budgets that don’t amplify outages, idempotency on receive — round out the collection. The recurring point: cloud-native is what the runtime cannot fake for you.

"We Store Secrets in appsettings.json": A Horror Story in Five Acts

Every Azure subscription I’ve worked with has the same problem: connection strings with embedded credentials in appsettings.json, Service Principal secrets checked into Git history, storage account keys hardcoded everywhere. The credential sprawl is real. These aren’t careless developers. These are smart people applying on-premises patterns where they don’t belong. Azure Managed Identity flips the model entirely. Instead of your application proving identity by presenting a secret, Azure proves identity on your application’s behalf through cryptographic attestation. No secrets in code. No credentials in configuration. No rotation ceremonies. The Azure SDK’s DefaultAzureCredential handles authentication automatically, working identically in local development and production. Combined with RBAC, you scope permissions to exactly what each application needs. Not Contributor-level access to the entire subscription. Just the specific operations on specific resources that the application actually requires. This article walks through credential anti-patterns I encounter constantly, then shows the correct implementation using Bicep and .NET’s DefaultAzureCredential. The migration path is pragmatic: within weeks, not months, you can have zero static credentials in your codebase.

Why ISO Standards Actually Matter for .NET Developers

Cloud-native .NET development has transformed ISO/IEC 27001, 27017, and 27701 from abstract compliance requirements into concrete daily coding decisions. This guide shows .NET developers how security standards directly map to Azure Key Vault integration, Azure AD authentication, and proper logging—with real code examples demonstrating compliant vs. non-compliant implementations.

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.

Why Your Logging Strategy Fails in Production

Let me tell you what I’ve learned over the years from watching teams deploy logging strategies that looked great on paper and failed spectacularly at 3 AM when production burned.

It’s not that they didn’t know the theory. They’d read the Azure documentation. They’d seen the structured logging samples. They’d studied distributed tracing. The real problem was different: they knew what to do but had no idea why it mattered until production broke catastrophically.