Cloud native development

Cloud-native development represents a fundamental shift in how we design, build, and operate software applications in modern distributed environments. It embraces principles like containerization, microservices architecture, dynamic orchestration, and declarative APIs to create systems that are resilient, scalable, and manageable.

This collection explores the practical aspects of building cloud-native applications with .NET, including containerization strategies with Docker, orchestration with Kubernetes, service-to-service communication patterns, and distributed system design. Topics cover the architectural decisions, trade-offs, and operational challenges teams encounter when adopting cloud-native practices.

The articles examine how cloud-native principles influence application design, from stateless services and external configuration to health checks and graceful degradation. The focus remains on understanding when cloud-native approaches provide genuine benefits versus when traditional architectures remain more appropriate for specific use cases.

"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.