Last modified: Jan 31 2026 at 10:09 PM • 5 mins read

Review an Azure Container Apps Solution Architecture and Resources

Table of contents

  1. Overview
  2. Reference Scenario: Fabrikam Drone Delivery
  3. Solution Architecture Overview
  4. Container Apps Features in Action
  5. Azure Resources Required
  6. Runtime Architecture
  7. Development Environment Requirements
  8. CI/CD Pipeline Resources
  9. Key Takeaways

Overview

Before embarking on a cloud-native project, it’s essential to understand real-world solution architectures and resource requirements. This module examines a reference implementation that migrates from Azure Kubernetes Service (AKS) to Azure Container Apps.

Reference Scenario: Fabrikam Drone Delivery

The Business Context

Company: Fabrikam Inc.

Application: Drone Delivery - A microservices-based application for coordinating drone package deliveries

Current State: Running on Azure Kubernetes Service (AKS)

Problem: The team identified several inefficiencies:

  • Underutilization of advanced AKS features (custom service mesh, complex autoscaling)
  • Operational complexity requiring specialized Kubernetes expertise
  • Resource overhead from managing cluster infrastructure

Decision: Migrate to Azure Container Apps to simplify operations while retaining container benefits

Migration Goals

GoalBenefit
Simplify deploymentFaster time to production
Reduce complexityLess operational overhead
Enhance DevOpsStreamlined CI/CD processes
Save resourcesLower infrastructure costs
Retain benefitsKeep containerization advantages

Solution Architecture Overview

The Fabrikam Drone Delivery Application

The application consists of 5 microservices working together:

Architecture diagram showing Azure Container Apps environment with five microservices: Ingestion service receives external traffic via HTTP, Workflow service orchestrates processes and connects to Azure Service Bus and Managed Identities, Package service stores data in Azure Cosmos DB for MongoDB API, Drone Scheduler service manages timing with Azure Cosmos DB, and Delivery service handles deliveries using Azure Cache for Redis. All services share monitoring through Azure Log Analytics Workspace connected to Application Insights and Azure Monitor. Azure Key Vault provides secrets management for Managed Identities. The environment is contained within a light blue boundary representing the Azure Container Apps Environment

Key Architectural Features

  • ✅ HTTPS Ingress - External access to Ingestion service
  • ✅ Internal Service Discovery - Services communicate via DNS names (no hardcoded IPs)
  • ✅ Secrets Management - Secure configuration via Azure Key Vault
  • ✅ Managed Identities - Passwordless authentication to Azure services

Container Apps Features in Action

Feature Implementation Matrix

FeatureServices Using ItPurpose
HTTPS IngressIngestionExpose API to internet securely
Internal DiscoveryDelivery, DroneScheduler, PackageService-to-service communication
Managed IdentitiesDelivery, DroneSchedulerAuthenticate to Key Vault without secrets
Secrets ManagementPackage, Ingestion, WorkflowStore sensitive configuration
Container RegistryAll servicesPull Docker images from ACR
RevisionsWorkflowSafe deployments with rollback capability
ARM TemplatesAll servicesInfrastructure as Code
Log AnalyticsAll servicesCentralized logging and monitoring

Deployment Model

Revision Mode: Single revision (no A/B testing needed)

Scaling: Fixed replicas (1 per service) - no auto-scaling in this example

Sidecars: Not used - each replica = one container

Azure Resources Required

Core Container Apps Resources

ResourceQuantityPurpose
Container Apps Environment1Shared environment for all microservices
Container Apps5One per microservice (Ingestion, Workflow, Delivery, DroneScheduler, Package)
Container Registry1Store and distribute Docker images
Managed Identities5Secure authentication to Azure services
Key Vault5Secrets storage (2 actively used)

Supporting Azure Services

ResourceQuantityPurpose
Cosmos DB2Data persistence for Delivery and Package services
Redis Cache1Track in-flight deliveries (Delivery service)
Service Bus1Asynchronous messaging between services
Log Analytics1Centralized logging and diagnostics
Application Insights1Application performance monitoring

Networking Resources

ResourcePurpose
Virtual NetworkNetwork isolation
Private EndpointSecure connections to Azure services
Network InterfaceNetwork connectivity
Private DNS ZoneInternal name resolution

Runtime Architecture

How Services Communicate

External → Internal Flow:

  1. Client → HTTPS → Ingestion Service (public ingress)
  2. Ingestion → Service Bus Queue → Workflow Service
  3. Workflow → Internal DNS → Delivery, DroneScheduler, Package

Shared Environment Benefits

All 5 Container Apps share the same environment, enabling:

  • ✅ Internal service discovery - Call services by name, not IP
  • ✅ Single Log Analytics workspace - One place for all logs
  • ✅ Shared secrets management - Centralized configuration
  • ✅ Unified networking - Services communicate securely

Architecture diagram showing Azure Container Apps environment with five microservices: Ingestion service receives external traffic, Package service handles package data, Drone Scheduler coordinates timing, Delivery service manages deliveries, and Workflow service orchestrates processes. All services connect to Azure Container Registry on the left. On the right, the environment integrates with Azure Application Insights for monitoring and Azure Log Analytics workspace for centralized logging, which feeds into Azure Monitor for observability

Secrets Management Strategy

Hybrid Approach used for flexibility:

ServicesAuthentication MethodWhy
Delivery, DroneSchedulerManaged Identity → Key VaultNo code changes needed
Package, Ingestion, WorkflowContainer Apps SecretsSimpler for basic secrets

Development Environment Requirements

Required Accounts

  • ✅ Azure subscription (with appropriate permissions)
  • ✅ GitHub account (for source control)

Local Development Tools

ToolPurpose
Docker DesktopBuild and test containers locally
Visual Studio CodeIDE with Docker + Azure extensions
Azure CLICommand-line Azure management
PowerShellScripting and automation

Azure CLI Extensions

az extension add --name containerapp

CI/CD Pipeline Resources

Azure DevOps Setup

ComponentConfiguration
Project“Project1”
RepositoryContainer app source code
Pipeline“Pipeline1” (Starter template)
Build AgentSelf-hosted Windows agent

Deployment Process

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Code Commit │────▶│ Build Images │────▶│  Push to ACR │
└──────────────┘     └──────────────┘     └──────────────┘
                                                  │
                                                  ▼
                          ┌────────────────────────────────┐
                          │  Deploy to Container Apps      │
                          │  (ARM Templates)               │
                          └────────────────────────────────┘

Key Takeaways

Why This Migration Succeeded

  • ✅ Simplified Operations - No Kubernetes cluster management
  • ✅ Retained Benefits - Still containerized and cloud-native
  • ✅ Cost Reduction - Pay only for actual usage
  • ✅ Faster Deployments - Less complex CI/CD
  • ✅ Built-in Features - Service discovery, secrets, logging included

When Container Apps Is the Right Choice

This scenario is ideal for Container Apps because:

  • ❌ Don’t need Kubernetes API access
  • ❌ Don’t need custom service mesh
  • ❌ Don’t need complex autoscaling rules
  • ✅ Do need microservices communication
  • ✅ Do need simplified operations
  • ✅ Do need Azure service integration

Lessons Learned

  1. Start simple - Don’t over-engineer with AKS if Container Apps suffices
  2. Evaluate usage - Underutilized AKS is expensive
  3. Leverage managed services - Let Azure handle infrastructure
  4. Focus on apps - Spend time on business logic, not cluster management