CH04-03: Containers with Container Apps and AKS

Goal

The previous section compared managed application hosting with event-driven execution. This section moves to containers, where the packaging model and the platform model are often confused.

A container packages an application with the dependencies it needs to run consistently. Kubernetes is a platform for orchestrating containers across clusters of machines. Those are related ideas, but they are not the same decision.

The durable idea is:

Containers package applications; Kubernetes is a platform operating model.

The Short Version

Azure Container Apps is managed container hosting for applications, APIs, workers, microservices, and event-driven container workloads. It lets teams run containers with features such as ingress, revisions, scaling rules, jobs, and service-to-service communication without directly managing a Kubernetes cluster.

Azure Kubernetes Service, usually called AKS, is Azure's managed Kubernetes service. Azure manages important parts of the Kubernetes control plane, and newer AKS modes can reduce more operational work. But AKS still means the team is choosing Kubernetes as an operating model, with Kubernetes APIs, cluster concepts, networking, security, upgrades, capacity, and platform governance to understand.

The practical question is:

Do we need containers, or do we need Kubernetes control?

Those are not the same answer.

The Container Decision

Containers help when the team wants consistent packaging across environments.

They are useful when:

• The application needs dependencies that are easier to package with the app.

• The team wants the same artifact to run in development, test, and production.

• The workload is already containerized.

• Different services use different runtimes.

• Deployment pipelines are built around container images.

Using containers does not automatically require a full Kubernetes platform. A small API, worker, or event-driven service might benefit from container packaging without needing cluster-level control.

Use this branch as a starting point:

Need containers?
    |
    +-- Need Kubernetes APIs, ecosystem, or platform control?
    |       |
    |       +-- Yes -> Azure Kubernetes Service
    |
    +-- Need simpler managed container hosting?
            |
            +-- Yes -> Azure Container Apps

Azure Container Apps

Container Apps is a good fit when the team wants to deploy containers and keep platform operations lighter.

It can host:

• Containerized APIs.

• Background workers.

• Event-driven processors.

• Microservices that need service discovery and internal communication.

• Jobs that run on demand, on a schedule, or based on events.

Container Apps can scale based on HTTP traffic, events, CPU, memory, or KEDA-supported scaling triggers. Many workloads can scale down when idle, depending on the scaling mode and resource behavior.

The key architecture benefit is abstraction. The service is built on Kubernetes technology, but it does not give the team direct access to the underlying Kubernetes APIs. That is often a strength. If the team does not need Kubernetes objects, node pools, ingress controllers, cluster upgrades, and low-level scheduling control, avoiding that work can be a better design.

Azure Kubernetes Service

AKS is a good fit when Kubernetes itself is part of the requirement.

AKS becomes more justified when:

• The organization already standardizes on Kubernetes.

• Teams need Kubernetes APIs and ecosystem tools.

• The platform team provides shared Kubernetes patterns for many application teams.

• Workloads need advanced scheduling, service mesh, policy, or cluster-level extension patterns.

• Portability across Kubernetes environments matters.

• The team has the skills and operational model to run a Kubernetes platform responsibly.

Azure reduces the burden of running Kubernetes, especially around the control plane and managed features. But Kubernetes still changes the operating conversation. Someone must understand clusters, namespaces, workloads, secrets, ingress, network policy, node capacity, upgrades, observability, and platform security.

AKS is powerful. It is not a shortcut around platform thinking. It is platform thinking.

Comparison

This comparison is not about which service is better. It is about matching control to need.

Example: Worker Now, Platform Later

Suppose a SaaS team has a containerized notification worker. It reads messages, calls a notification provider, and writes delivery status. The team has a small operations group and no Kubernetes platform standard.

Container Apps is likely enough:

Message queue -> Container Apps worker -> Notification provider

The team can deploy a container, scale based on queue depth or events, observe logs, and avoid building a cluster platform just for one worker.

Now imagine a different organization. It has twenty product teams, a platform engineering group, shared Kubernetes policies, standard Helm charts, service mesh patterns, and workloads already designed for Kubernetes. In that environment, AKS may be the right answer because Kubernetes is the shared platform language.

The same container image could technically run in either place. The architecture answer changes because the organizational operating model changes.

Common Mistakes

• Saying "we use containers" and jumping straight to AKS.

• Ignoring cluster operations, upgrades, policy, node capacity, networking, and security.

• Choosing Container Apps while expecting every low-level Kubernetes control.

• Forgetting that container platform choice affects identity, observability, deployment pipelines, and traffic design.

• Treating Kubernetes as a developer convenience without funding the platform ownership it requires.

If Someone Asks You

When would you choose Container Apps instead of AKS?

A good answer is:

I choose Container Apps when the workload benefits from containers but the team does not need direct Kubernetes control. It is a strong fit for APIs, workers, jobs, and event-driven container workloads where managed hosting and simpler operations matter. I choose AKS when Kubernetes APIs, ecosystem tools, platform standards, or advanced control justify the extra operating responsibility.

What You Should Remember

Use containers when packaging helps; choose Kubernetes only when its control model is worth operating.

Questions to Check Your Understanding

1. What is the difference between a container and Kubernetes?

2. Why might Container Apps be enough for many containerized workloads?

3. What extra responsibilities should a team expect with AKS?