Cloud Computing and Cloud Architecture
The cloud is not a deployment target. It is a different operating model with different identity primitives, a different cost model, and a different definition of what “available” means. Articles tagged here focus on the platform-specific decisions — Azure managed services, identity federation, regional design, billing — that decide whether a workload behaves like a cloud system or like a lift-and-shift that happens to run in someone else’s data centre.
Managed-service content sits at the centre of the collection. Azure SQL versus a self-managed instance is not only a price comparison; it is a decision about who owns patching, backup, failover, and the audit trail those operations produce. App Service versus Container Apps versus AKS is not a runtime question alone — each tier changes which knobs the platform owns and which the team has to operate. The articles name what each managed boundary actually covers, because the marketing material rarely does.
Identity is the second recurring theme. Managed Identity replaces stored credentials with Azure-attested tokens; Workload Identity Federation extends the same model to AKS and cross-tenant scenarios; conditional access enforces device and location constraints that ASP.NET Core authorization policies cannot see. Articles cover the wiring on both sides — Bicep for the role assignment, DefaultAzureCredential for the consumption — and the failure modes that show up only in production.
Cost-model articles treat consumption pricing as an architectural input. Cold-start latency in Functions, throughput units in Event Hubs, RU/s in Cosmos DB — each is a decision that shows up on the invoice before it shows up in a design review.
For container and twelve-factor patterns that apply across providers, see the cloudnative tag. This collection stays on the cloud-platform side of the line: the managed services, identities, and regional choices that only exist because a hyperscaler runs them.
AKS Cost Optimization: Resource Governance That Actually Works
AKS costs are brutally simple: node sizing, pod density, workload sprawl, and reserved capacity. If you don’t have visibility and governance, your cloud bill will punch you in the face—usually when it’s too late to react without pain. I’ve watched teams scramble to cut costs after the invoice lands, breaking production in the process. This guide is for practitioners who want to avoid that mess. No theory, no vendor fluff: just what actually works to keep AKS costs under control without sacrificing reliability.
Storage Architecture & Stateful Workloads in AKS
Your appsettings.json Is a Compliance Violation
AKS Cluster Upgrades: Zero-Downtime Operations That Actually Work