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.

Pod Identity & Access Control in AKS: What Actually Breaks

Pod Identity & Access Control in AKS: What Actually Breaks

Traditional AKS authentication relied on service principals and mounted secrets. Workload Identity Federation eliminates credential lifecycle problems, but introduces new failure modes. This article covers the operational realities: where credentials still leak, how RBAC layers compound across Kubernetes and Azure, and validation patterns that prevent identity failures in production.
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.
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.

AKS Networking Clash: kubenet vs. CNI vs. CNI Overlay

AKS Networking Clash: kubenet vs. CNI vs. CNI Overlay

Selecting the right network model is arguably one of the most critical architectural decisions you will make when deploying a Kubernetes cluster on Azure Kubernetes Service (AKS). This choice ripples through nearly every aspect of your cluster’s lifecycle, influencing how pods communicate, how efficiently you use your IP address space, which Azure services integrate seamlessly with your workloads, and ultimately, how well your infrastructure scales to meet future demands. It affects scalability, security posture, operational cost, performance characteristics, available integration options, and your long-term operational flexibility.