CH10-03: Runtime Platform with Container Apps or AKS

Goal

Once service boundaries and ownership are clear, the next question is where those services should run. In Azure, containerized microservices commonly lead teams to compare Azure Container Apps and Azure Kubernetes Service, often shortened to AKS.

Azure Container Apps is a managed container application platform. It lets teams run containerized applications without managing a Kubernetes cluster directly. AKS is Azure's managed Kubernetes service. It gives teams Kubernetes APIs and ecosystem control, while still leaving more platform responsibility with the organization.

The durable idea is:

The microservice runtime should fit the team's platform maturity and control needs.

The Short Version

The easy assumption is:

Microservices mean Kubernetes.

The better architecture question is:

How much runtime control can the team use responsibly?

Both Container Apps and AKS can run microservice workloads. The difference is not that one is "microservices" and the other is not. The difference is the operating model.

Microservice runtime choice
    |
    +-- Need managed container hosting with lower platform overhead?
    |       -> Azure Container Apps
    |
    +-- Need Kubernetes APIs, ecosystem control, or platform standardization?
            -> Azure Kubernetes Service

What Container Apps Gives You

Container Apps is a strong fit when the team wants to run containers but does not want to operate a Kubernetes platform directly. It can host containerized services, expose ingress, scale applications, support revisions, integrate with secrets, and run event-driven workloads.

For many product teams, that is enough. They can focus on service code, contracts, data ownership, deployment pipelines, and observability instead of cluster node pools, Kubernetes add-ons, upgrade planning, and platform engineering.

Container Apps is often attractive when:

• Services are containerized but platform needs are moderate.

• The team wants managed scaling and deployment revisions.

• The organization does not yet have a dedicated Kubernetes platform team.

• Workloads fit the platform's networking, ingress, and operational model.

• The architecture benefits from reducing infrastructure surface area.

This does not mean Container Apps removes all operations. Teams still own application health, configuration, secrets use, identity, networking decisions, logs, metrics, alerts, deployment quality, and cost.

What AKS Gives You

AKS is a strong fit when the organization deliberately wants Kubernetes as a platform boundary. Kubernetes provides a broad API and ecosystem for scheduling, service discovery, ingress, policy, networking integrations, workload identity patterns, deployment controllers, and platform add-ons.

AKS may be justified when:

• The organization already has Kubernetes skill and platform ownership.

• Multiple teams need a standardized Kubernetes platform.

• Workloads need Kubernetes APIs, controllers, operators, or ecosystem tools.

• Networking, ingress, service mesh, policy, or add-on control matters.

• The platform team can own upgrades, cluster security, node pools, observability, and operational standards.

AKS reduces the burden of building Kubernetes from scratch, but it does not make Kubernetes disappear. The organization still needs to operate the cluster as a product that service teams can safely use.

Runtime Responsibilities

Regardless of platform, microservices need runtime discipline:

This is why runtime choice is an architecture decision, not just an infrastructure preference.

Example: Two Reasonable Choices

A small product team is splitting a commerce application into catalog, orders, payments, and recommendations. The team has strong application engineers but no dedicated Kubernetes platform team. Container Apps may be the better starting point. It gives the team container hosting and scaling with lower platform overhead.

A large enterprise has dozens of service teams, an existing platform engineering group, standardized Kubernetes security controls, and shared ingress, policy, and observability tooling. AKS may be a better fit because the organization can turn Kubernetes into a managed internal platform.

Both choices can be mature. The wrong answer is choosing AKS only because the word microservices appears in the design.

Common Mistakes

• Treating every container platform as the same operating model.

• Choosing AKS because microservices sound like Kubernetes.

• Ignoring who owns runtime upgrades, networking, security baselines, and incident support.

• Assuming Container Apps removes the need for application observability and deployment discipline.

• Letting each service team invent its own runtime patterns without platform standards.

If Someone Asks You

How do you choose between Container Apps and AKS for microservices?

A good answer is:

I choose by control needs and operating maturity. Container Apps is often a good fit when teams want managed container hosting with less platform overhead. AKS is justified when the organization needs Kubernetes APIs, ecosystem control, advanced platform standardization, and has the skills to operate it. In either case, the team still needs clear scaling, deployment, networking, secrets, identity, observability, and support ownership.

What You Should Remember

Choose the runtime platform by control needs and operating maturity.

Questions to Check Understanding

1. What does Container Apps reduce for a team?

2. What does AKS give in exchange for more responsibility?

3. Why is platform ownership part of the architecture?