Kubernetes vs Serverless Platforms in Azure
AKS gives you the full Kubernetes platform — complete control, full API access, and the operational complexity that comes with it. Azure Functions and Azure Container Apps are serverless platforms that remove most of that complexity in exchange for constraints. Choosing between them is a decision about how much operational control your team needs versus how much complexity it can absorb.
What each platform provides
Azure Kubernetes Service (AKS) is a managed Kubernetes service. Microsoft manages the control plane (free of charge); you manage the worker nodes (VMs you pay for), the cluster configuration, node pool scaling, networking, and all Kubernetes resources (Deployments, Services, Ingress, PersistentVolumeClaims, etc.). AKS gives you the full Kubernetes API — any workload that runs on Kubernetes runs on AKS.
Azure Functions is a function-as-a-service platform. You write code in a supported runtime, deploy it as a function app, and Azure handles all infrastructure. The unit of deployment is a function (or function app). Azure Functions hides the concept of containers entirely from the developer.
Azure Container Apps sits between the two. It is a managed container platform built on Kubernetes, but the Kubernetes API is not exposed. You deploy container images, configure scaling rules (HTTP, KEDA event sources), and Azure manages the underlying cluster. Container Apps supports Dapr for inter-service communication and KEDA for event-driven scaling.
Comparison across key dimensions
| Dimension | AKS | Azure Functions | Azure Container Apps |
|---|---|---|---|
| Operational complexity | High — cluster, node pools, networking, upgrades | Near zero | Low |
| Kubernetes API access | Full | None | None (hidden layer) |
| Scale to zero | Yes (with KEDA, but nodes still cost money) | Yes (Consumption plan) | Yes (Consumption profile) |
| State management | StatefulSets, persistent volumes | Stateless; Durable Functions for orchestration | Containers support local state; ephemeral |
| Networking control | Full — Ingress, Network Policies, service mesh | Limited (VNet integration on Premium) | Good — built-in ingress, VNet integration |
| Debugging experience | Direct pod access, exec, log streaming | Local emulator, Application Insights | Container logs, Application Insights, console |
| Vendor lock-in risk | Low — standard Kubernetes, portable workloads | High — Functions SDK is Azure-specific | Medium — containers portable, env config is Azure-specific |
| Pricing model | Pay for node VMs + managed disk | Per execution + GB-second | Per vCPU-second + GiB-second (Consumption) |
Operational complexity in practice
Running AKS in production means owning: node pool upgrades (Kubernetes version and OS patches), cluster autoscaler configuration, persistent volume claims and storage classes, Ingress controllers and TLS certificates, network policies, RBAC, monitoring with Container Insights, and node pool sizing across multiple node types if you have GPU or spot nodes.
Azure Functions requires: writing the function code, configuring the trigger, setting up Application Insights, and choosing a hosting plan. There is no cluster to manage, no nodes to upgrade, no networking manifests to write.
Azure Container Apps sits between: you manage container images and revision configurations, but Azure owns the cluster, nodes, and Kubernetes internals. The operational surface is roughly 20% of AKS.
The critical question is not which platform is easier, but whether your team’s workload complexity justifies AKS’s operational overhead. A team of 3 engineers running 5 microservices does not need AKS. A platform team managing 50 services with custom networking, stateful workloads, and multiple teams deploying to the same cluster probably does.
Scaling behaviour
All three platforms scale out in response to demand, but with different mechanics and cost implications:
- AKS: The Horizontal Pod Autoscaler (HPA) scales pods based on CPU/memory; KEDA extends this to event-driven metrics. The Cluster Autoscaler adds or removes nodes. When demand drops, pods scale down but nodes may take several minutes to remove (and cost money until they do). Scale-to-zero is possible at the pod level with KEDA but nodes are still billed.
- Azure Functions (Consumption): Scales from 0 to hundreds of instances automatically within seconds. Each instance handles one invocation at a time (unless set otherwise). Scales to zero during idle periods — zero cost.
- Container Apps (Consumption): Scales from 0 replicas to the configured maximum based on HTTP concurrency or KEDA rules. During zero-replica state, the application is unresponsive until a new replica starts (cold start, typically 2–10 seconds for containers).
AKS Automatic (preview) and AKS node auto-provisioning features reduce some cluster management overhead, but they do not eliminate the need to understand Kubernetes resource models, networking, and upgrade management. They reduce toil, not complexity.
When Kubernetes (AKS) wins
- Your team already runs Kubernetes and the operational cost is absorbed into existing practice.
- You need full Kubernetes API access — custom controllers, CRDs, admission webhooks, service mesh (Istio, Linkerd).
- Workloads include StatefulSets with persistent volumes, complex node affinity rules, or GPU nodes.
- Multiple teams deploy to the same cluster and need Kubernetes-native multi-tenancy (namespaces, RBAC, resource quotas).
- You need to avoid vendor lock-in on the orchestration layer — Kubernetes workloads can move to any other cloud’s managed Kubernetes.
When serverless platforms win
- Workloads are event-driven with variable traffic — Functions Consumption plan is cheapest for this pattern.
- The team is small and does not have Kubernetes expertise — Container Apps provides scalable microservices without cluster management.
- Speed of deployment matters more than control — Container Apps can go from container image to production HTTPS endpoint in under 10 minutes.
- You want to avoid the ongoing operational cost of cluster management entirely.
- Workloads scale to zero and the idle cost savings are material to your budget.
Common mistakes
- Adopting AKS because it is the “enterprise” choice without the team to run it. AKS requires Kubernetes expertise. A team that deploys an AKS cluster and then struggles with upgrades, networking failures, and pod scheduling issues is paying an operational cost that far exceeds the benefit for simple workloads.
- Treating Container Apps as “just managed AKS.” Container Apps hides the Kubernetes API. If you need direct kubectl access, CustomResourceDefinitions, or Helm charts, you need AKS — Container Apps cannot satisfy these requirements.
- Ignoring cold starts on Container Apps scale-to-zero. When a Container Apps revision has zero replicas, the first request waits for a container to start. For production APIs where every request matters, set minimum replicas to 1 during business hours.
- Underestimating AKS networking complexity. AKS networking requires choosing a CNI plugin (Azure CNI, kubenet, or Azure CNI Overlay), planning IP address space, configuring Ingress controllers, and potentially managing Network Policies. Getting this wrong causes production outages that are difficult to debug.
Summary
- AKS provides full Kubernetes API access and maximum control at the cost of significant operational complexity — appropriate for platform teams managing complex, multi-service environments.
- Azure Functions eliminates all infrastructure management and scales to zero — ideal for event-driven workloads where simplicity and cost efficiency matter most.
- Azure Container Apps is the middle ground: managed container platform with autoscaling, VNet integration, and Dapr support, without Kubernetes expertise requirements.
- Choose based on your team’s actual operational capacity, not on what the “enterprise” default appears to be.
Frequently asked questions
Is Azure Container Apps just Kubernetes under the hood?
Yes. Azure Container Apps runs on AKS clusters managed by Microsoft. However, the Kubernetes API is not exposed to users — Container Apps presents its own simpler API. You get KEDA-based scaling and Dapr integration without managing any Kubernetes resources directly.
Can I run stateful services on serverless platforms in Azure?
Azure Functions is designed to be stateless. Durable Functions adds stateful orchestration patterns (workflows, actors, fan-out) but requires explicit design around durability. Container Apps supports stateful containers but at-rest local state is lost when containers are replaced. For stateful services, AKS with StatefulSets and persistent volumes provides more control.
What is KEDA and which platforms support it?
KEDA (Kubernetes Event-Driven Autoscaling) is an autoscaler that scales workloads based on external event sources — queue depth, Kafka lag, HTTP request count, database rows, and dozens more. Both AKS and Azure Container Apps support KEDA. Azure Functions also uses KEDA internally for scale-out in Kubernetes-hosted deployments.