Azure Container Apps for Beginners - Run Microservices Without Kubernetes

You already know how to:

• Build a .NET API
• Package it with a Dockerfile
• Run multiple services locally with Docker Compose
• Deploy using GitHub Actions

The next question is: where should these containers run in production?

For many teams the answer is Azure Container Apps.

It gives you the power of containers and microservices without the complexity of managing Kubernetes.

1. What is Azure Container Apps?

Azure Container Apps is a serverless platform for running containerized applications.

You give it a container image.
Azure takes care of:

• Running the containers
• Scaling them up and down
• Networking
• HTTPS
• Load balancing
• Updates to the underlying infrastructure

You do not manage virtual machines or Kubernetes clusters.

Common use cases:

• REST APIs
• Microservices
• Background workers
• Event-driven processing
• Jobs that run on a schedule

2. The Problem It Solves

When you start with containers you usually face this choice:

App Service is great for a single API.
AKS is powerful but requires Kubernetes knowledge and ongoing cluster management.

Azure Container Apps sits in the middle.

It is built on Kubernetes technologies under the hood, but you never see or manage the cluster.

3. Core Concepts You Must Know

Container Apps Environment

An Environment is a secure boundary around a group of container apps.

Think of it as a private neighborhood:

• Apps inside the same environment can easily talk to each other
• They share the same virtual network
• They share the same logging destination

Most projects start with one environment for development and another for production.

Container App

A Container App is your actual application (one microservice).

Examples:

• order-api
• payment-worker
• notification-service

Each container app usually runs one main container (you can also add sidecars later).

Revision

Every time you deploy a new version of your app, Container Apps creates a Revision.

Revisions allow:

• Zero-downtime deployments
• Traffic splitting (for example 90% old version, 10% new version)
• Easy rollback

This is one of the most powerful features for production.

Ingress

Ingress controls how traffic reaches your app.

• External → reachable from the public internet
• Internal → only reachable by other apps inside the same environment

You also set the target port (for example 8080).

Scaling

Container Apps can scale based on:

• HTTP traffic
• CPU or memory usage
• Event sources (queues, etc.)
• Custom rules (powered by KEDA)

It also supports scale to zero.
When there is no traffic, the app can go idle and you stop paying for compute.

4. Simple Mental Model

Docker Image (from your Dockerfile)
        ↓
Azure Container Registry
        ↓
Azure Container Apps
        ↓
Environment
   ├── Container App 1 (API)
   ├── Container App 2 (Worker)
   └── Container App 3 (Another service)

You still build images the same way.
You just change where those images run.

5. How It Fits With What You Already Learned

Typical modern flow:

Local development     → Docker Compose
Build & push image    → GitHub Actions + ACR
Run in production     → Azure Container Apps

6. Basic Deployment Flow

1. Create a Container Apps Environment
2. Build your Docker image (locally or in CI)
3. Push the image to Azure Container Registry
4. Create a Container App that points to that image
5. Configure ingress, scaling, and environment variables
6. Later updates create new revisions automatically

You can do the first deployment from:

• Azure Portal
• Azure CLI
• Visual Studio
• GitHub Actions

7. Example GitHub Actions Idea

A typical production pipeline looks like this:

Push to main
     ↓
GitHub Actions
     ↓
Build Docker image
     ↓
Push to Azure Container Registry
     ↓
Update the Container App (new revision)

Azure provides an official action (azure/container-apps-deploy-action) that can build from a Dockerfile and deploy in one step, or deploy an already pushed image.

8. When Should You Choose Container Apps?

Choose Azure Container Apps when:

• You are building microservices
• You want scale-to-zero
• You want easy traffic splitting and revisions
• You do not want to manage Kubernetes
• You already use Docker

Stay with App Service when:

• You have a simple single API or website
• You prefer the classic deployment model
• You do not need advanced container features

Move to AKS when:

• You need full Kubernetes API access
• You have complex networking or custom operators
• You already have a platform team that manages clusters

For most .NET teams starting with containers and microservices, Container Apps is the sweet spot.

9. Advantages for Beginners

• No cluster to manage
• Built-in HTTPS and domains
• Easy scaling rules
• Revisions make deployments safer
• Works naturally with the Docker images you already build
• Good integration with GitHub Actions
• Supports Dapr if you later need service discovery or pub/sub

10. Final Takeaway

Azure Container Apps lets you run containers in production without becoming a Kubernetes expert.

The simple mental model is:

Your Docker image
      ↓
Azure Container Apps
      ↓
Azure manages the infrastructure
      ↓
You focus on your services

You keep using:

• Dockerfile to package the app
• Docker Compose for local development
• GitHub Actions for CI/CD

Container Apps becomes the production home for those images.

Once you are comfortable deploying one service, you can add more container apps into the same environment and start building real microservices.

This is the natural next step after learning Docker and CI/CD.