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 at Scale: Hard-Won Lessons from 1000+ Node Clusters

AKS at Scale: Hard-Won Lessons from 1000+ Node Clusters

Running AKS at 1,000+ nodes exposes hard limits in etcd, networking, observability, and cost that never appear in vendor documentation. This article shares operational lessons from mega-cluster deployments: where the scaling cliffs are and how to plan around them before production outages force your hand.
Why Your Azure Portal Clicks Will Fail the Next Audit

Why Your Azure Portal Clicks Will Fail the Next Audit

Manual portal configuration creates audit nightmares. When auditors ask “Show me your change control process,” clicking through Azure Activity Logs won’t save you. Here’s how Bicep turns infrastructure into auditable code—where Git history becomes your compliance evidence and pull requests become your approval workflow.
Hybrid AKS: Bridging Cloud and On-Prem with Azure Arc

Hybrid AKS: Bridging Cloud and On-Prem with Azure Arc

Most organizations run Kubernetes across cloud and on-prem simultaneously. This article covers practical patterns for hybrid AKS: ExpressRoute and VPN connectivity, Azure Arc for unified management, consistent policy enforcement, DNS resolution, and identity federation without duplicating systems.
Your Azure SQL Backups Won't Save You (Here's Why)

Your Azure SQL Backups Won't Save You (Here's Why)

“We have backups” is the IT equivalent of “thoughts and prayers.” Comforting words that mean nothing when disaster strikes. I’ve watched teams discover their Azure SQL Database backups expired just before an audit, or worse, during an actual outage. The default seven-day retention feels generous until you need data from day eight.

Compliance standards demand information backup in cloud environments, but no standard can enforce what most teams ignore: actually testing those backups. The gap between “we configured backups” and “we can restore our data” has ended careers and companies. This isn’t about checking compliance boxes. It’s about whether your business survives the next outage.

AKS Disaster Recovery: Why Your Untested Backup Will Fail

AKS Disaster Recovery: Why Your Untested Backup Will Fail

Your cluster will fail. The question is not if, but when, and whether you can recover before customers notice. Most organizations discover their backup strategy does not work during an actual outage, when recovery time matters most and manual heroics cannot save you.

If you run Azure Kubernetes Service (AKS) in production, you need a recovery plan that engineers can execute half asleep at 2 AM. We will go through what to back up, how Velero works in day-to-day operations, when Azure Backup for AKS is enough, and how to design realistic failover with measurable Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The goal is simple: repeatable recovery procedures you have already tested, not a document that looks good in Confluence but fails during an incident.