Do You Really Need Kubernetes in a Modern Azure Environment?

Product wanted three new features, Infra wanted an AKS pilot, and Finance wanted fewer surprises. My team had beautiful YAML, my roadmap had a launch date. This is how we picked the least platform that shipped outcomes now, with a clean ramp to later and how we make that call on Azure, every time.

• If it’s a web/API in 90 days , we go App Service/Web Apps for Containers.
• If traffic is spiky or we want scale-to-zero , we go Azure Container Apps.
• If it’s a job, not a service , we run it on ACI.
• If we’re building a platform (mesh/operators/policy), we choose AKS on purpose, with budget.

We started where Azure shines when you want speed with guardrails. App Service (code) when the runtime fit: push, slot-swap, go. Web Apps for Containers when we brought our own image: same smooth CI/CD, still no cluster to babysit. That bought us immediate wins: fewer moving parts, clear costs, and enough scale for the first wave of customers. No one was SSH’ing into anything at 2 a.m., and the team shipped features instead of node pools.

When traffic grew and architectures got spikier, we explored the rest of the city picking streets, not building flyovers. Azure Container Apps (ACA) covered event-driven bursts, scale-to-zero, revisions/traffic splitting, and Dapr for sidecars without summoning a platform team. Azure Container Instances (ACI) became our courier lane: "run this job now, finish, and bill by the second." And AKS ? We reserved it for when we truly needed custom controllers, mesh, advanced CNI/policy, or we were formalizing an internal platform for many teams.

A small story with a loud lesson: twelve services, one region, small team, bursty workloads. We flirted with AKS (as one does). Two weeks in, we were picking ingress controllers, designing RBAC, planning upgrades and not shipping features. We paused, put web/APIs on App Service/Web Apps for Containers , moved chatty bits to Container Apps , and ran scripts on ACI . Result: same reliability, ~zero cluster work, releases back to twice a week, and a cloud bill that actually dipped on quiet days thanks to scale-to-zero. The only thing we missed was the adrenaline.

Azure Options Side-by-Side

Service	Ops Model	Team You Need	Scale & Cost Posture	Release Controls	Networking/Identity	Hidden Gotchas
App Service (Code)	PaaS (no container)	App devs	Plan autoscale; predictable	Slots, swap, CI/CD	Easy VNet integration, Managed Identity	Custom runtimes/sidecars awkward
Web Apps for Containers	PaaS (your image)	App + basic Docker	Plan autoscale; simple ops	Slots, swap, CI/CD	Similar to above	Not an orchestrator—keep the app simple
Azure Container Apps	Serverless containers	App devs (no cluster ops)	Scale-to-zero; KEDA bursts; pay-for-usage	Revisions, traffic split	Environments, Private Endpoints, Managed Identity	Fewer deep K8s knobs (by design)
Azure Container Instances	Serverless single container/group	No ops	Per-second billing	N/A (job-style)	Basic VNet options	Not for always-on services/ingress
AKS (Azure Kubernetes Service)	Managed Kubernetes	Platform + SRE	Node/pod autoscale; most flexible	Helm, blue/green, canaries	Full CNI, policy, mesh, operators	Highest learning & ops overhead

TCO on a Whiteboard (No Mysticism, Just Math)

When Finance asked for the why behind our choices, we drew four boxes:

• People cost/month: platform FTEs to run & evolve AKS (upgrades, CNI, RBAC, ingress, policy, observability).
• Infra baseline/month: plan or node costs + networking + logging/metrics.
• Change tax: average change lead time × changes/month × blended engineer rate.
• Risk premium: incident hours × blended rate (blast radius matters).

If AKS total ≤ ACA/App Service total and platform ownership is funded, greenlight AKS. Otherwise, keep it simple and keep shipping.

When AKS Is the Right Starting Point

Sometimes the platform is the product. We start with AKS when we’re building multi-tenant SaaS in regulated environments , need custom controllers/CRDs, service mesh, or nuanced network policy , or we’re explicitly creating an internal developer platform used by many teams. In those cases, we fund a platform squad, set SLOs for the platform itself, and pilot AKS in one bounded domain first.

A Migration Path That Won’t Derail a Quarter

1. Today: Put web/APIs on App Service/Web Apps for Containers ; run background jobs on ACI . Centralize secrets (Key Vault) and telemetry (Monitor). Boring is good.
2. When spikes arrive: Move chatty or event-driven services to Container Apps . Use revisions for blue/green and autoscale to pay for what you use.
3. When the platform is the product: Pilot AKS for one domain. Ring-fence with clear SLOs and budget a platform squad. Talk meshes/operators only after that pilot proves value.

Anti-Patterns (A Gentle Roast)

• "We might need it later" K8s: future-proofing isn’t a business case.
• Everything-in-K8s on day one: congrats, you built a platform before a product.
• Shadow ops: if your PMs don’t know who owns the cluster, you own the cluster.

FAQ

Will we outgrow Azure Container Apps?
Only if you need deep K8s features (operators, service mesh, bespoke policy). Many teams never do.

Can we mix services?
Yes. App Service + ACA + ACI is a common, sensible combo; use each for its sweet spot.

How do we know it’s time for AKS?
When platform requirements are written down, funded, and tied to business constraints not vibes.

Bottom Line

Kubernetes isn’t a strategy; it’s a wager. On Azure, the winning bet is to start with App Service/Web Apps for Containers , graduate to Container Apps when your workload shape demands it, and adopt AKS only when your requirements and your organization are unmistakably platform-ready.

Your customers will feel the faster delivery. Your engineers will feel fewer 2 a.m. "one more YAML tweak" moments. And your CFO will feel a calmer cloud bill 😉