Building a Blog with Next.js and Azure

In this post, I walk through the architecture of this very blog.

Tech Stack

Layer	Technology
Frontend	Next.js 14, React, Tailwind CSS
Backend	Next.js API Routes, Prisma ORM
Database	Azure PostgreSQL Flexible Server
Hosting	Azure Kubernetes Service (AKS)
CI/CD	GitHub Actions
IaC	Bicep / ARM Templates

Architecture

The blog follows a monorepo structure using Turborepo...

More details coming in a future post!

Current State

Resource	Count	Details
Nodes (VMs)	1	Standard_DS2_v2 — 2 vCPU, 4 GB RAM, Ubuntu 22.04
Pods (your app)	1	web-5c94d98bf7-87vhx — single replica
Replicas	1	Deployment spec says replicas: 1

---

Resiliency Right Now: Minimal

What happens if things fail:

Failure	Impact	Recovery
Pod crashes	Site is down	K8s auto-restarts pod (~10–30s)
Node (VM) dies	Site is down	AKS VMSS replaces node (~5–10 min)
AKS control plane issue	Site stays up	Azure SLA handles it (data plane separate)
PostgreSQL goes down	Site is down	Azure Flex Server auto-recovery
Redis goes down	Partial degradation	Azure Redis auto-recovery

In short: With 1 node and 1 pod, any failure = brief downtime.
K8s will auto-heal, but there's a gap.

---

What Production Resiliency Looks Like

For a personal blog, this is honestly fine. But if you want proper HA:

• Replicas: 2–3 pods — survives pod crashes with zero downtime
• Nodes: 2–3 across availability zones — survives VM/zone failures
• Pod Disruption Budgets — ensures rolling updates don't kill all pods
• Health probes (liveness + readiness) — K8s auto-routes away from unhealthy pods
• HPA (Horizontal Pod Autoscaler) — scales pods based on CPU/memory

---

For a personal blog with you as the sole admin, 1 node / 1 pod is cost-effective and sufficient — K8s auto-restart covers most failures within seconds.