Was ist Azure Container Apps?
Azure Container Apps ist eine serverless Container-Plattform von Microsoft Azure, die es ermöglicht, containerisierte Anwendungen ohne Kubernetes-Cluster-Management zu betreiben. Der Service kombiniert die Flexibilität von Containern mit der Einfachheit von Serverless: Sie deployen Container-Images, Azure kümmert sich um Scaling, Networking, Load Balancing und Infrastruktur. Im Gegensatz zu Azure Kubernetes Service (AKS) benötigen Sie kein Kubernetes-Wissen und verwalten keine Nodes.
Der Kern von Container Apps ist das Environment, eine Sicherheits- und Netzwerkgrenze, in der mehrere Container Apps laufen. Innerhalb eines Environments können Apps über Service Discovery kommunizieren, teilen sich VNET-Integration und Logs. Jede Container App besteht aus einem oder mehreren Containern (Multi-Container-Support), die als Revision deployen. Revisions sind immutable: Jedes Update erstellt eine neue Revision, alte bleiben verfügbar für Traffic Splitting oder Rollback.
Ein Alleinstellungsmerkmal ist die KEDA-Integration (Kubernetes Event-Driven Autoscaling): Container Apps skalieren nicht nur auf HTTP-Traffic, sondern auch auf Events wie Azure Queue-Länge, Kafka-Topics, RabbitMQ, Cron-Schedules oder Custom Metrics. Das ermöglicht scale-to-zero bei Inaktivität (0 Kosten) und automatisches Hochskalieren bei Last. Dapr (Distributed Application Runtime) ist nativ integriert für Microservices-Patterns wie Service Invocation, Pub/Sub oder State Management, ohne dass Sie eigene Service Meshes implementieren müssen.
Typische Anwendungsfälle
Microservices-Architektur ohne Kubernetes-Komplexität
E-Commerce-Plattformen mit 20+ Microservices (Product-Service, Cart-Service, Payment-Service) deployen auf Container Apps statt AKS, um Kubernetes-Overhead zu vermeiden. Jeder Service ist eine Container App mit eigenem Scaling-Profil. Frontend-Services skalieren auf HTTP-Requests, Backend-Worker auf Queue-Länge. Dapr ermöglicht Service-to-Service-Kommunikation ohne Hardcoded URLs. Deployment via Bicep oder Terraform, keine YAML-Manifeste.
Event-Driven Background-Worker
SaaS-Plattformen verarbeiten asynchrone Jobs (PDF-Generierung, Bild-Resize, E-Mail-Versand) über Azure Queue Storage oder Service Bus. Container Apps mit KEDA-Scaling skalieren Worker-Container basierend auf Queue-Länge: 0 Replicas bei leerer Queue, bis zu 30 Replicas bei Peaks. Kosten fallen nur während Verarbeitung an. Alternative zu Azure Functions für Workloads, die mehr als 10 Minuten laufen oder komplexe Dependencies haben.
API-Backends für Mobile Apps
Mobile Apps (iOS, Android) kommunizieren mit REST-APIs, die als Container Apps laufen. Auto-Scaling auf HTTP-Traffic garantiert Performance bei Spitzenzeiten (z.B. Black Friday). VNET-Integration schützt Backend-Datenbanken (Azure SQL, Cosmos DB) vor öffentlichem Zugriff. Managed Identity für passwortlose Authentifizierung. Ingress mit TLS-Termination und Custom Domains. Scale-to-zero für Dev/Test-Umgebungen spart Kosten.
Multi-Region SaaS mit Geo-Failover
B2B-SaaS-Plattformen deployen Container Apps in West Europe und East US für niedrige Latenz. Azure Front Door routet Requests zur nächstgelegenden Region. Bei Region-Ausfall automatischer Failover. State wird über Cosmos DB Multi-Region oder Redis Enterprise synchronisiert. Jede Region ist autark, Deployments über Azure DevOps Pipelines mit Region-spezifischen Parametern.
Batch-Processing und Scheduled Jobs
Data-Engineering-Teams verarbeiten nächtliche ETL-Jobs (Extract-Transform-Load) als Container Apps mit Cron-KEDA-Scaler. Jobs starten um 2 Uhr nachts, verarbeiten Millionen Datensätze aus Blob Storage, schreiben zu SQL Data Warehouse. Container Apps skalieren auf benötigte Parallelität (z.B. 50 Worker), danach scale-to-zero. Günstiger als dedizierte VMs, flexibler als Azure Functions (kein 10-Minuten-Limit).
Modernisierung von Legacy-Apps
Unternehmen containerisieren On-Premises-Anwendungen (Java, .NET, Python) und migrieren zu Container Apps statt kompletter Rewrite. Lift-and-Shift-Migration ohne Kubernetes-Learning-Curve. VNET-Integration für Hybrid-Connectivity zu On-Premises-Datenbanken über ExpressRoute. Managed Identity ersetzt hardcoded Credentials. Blue-Green-Deployments über Revisions minimieren Risiko.
Best Practices für Azure Container Apps
Environment-Design für Isolation
Erstellen Sie separate Environments für dev, staging, production statt einer großen Shared-Environment. Jedes Environment hat eigene VNET-Integration, Log Analytics Workspace und Kostentagging. Production-Environments in separaten Subscriptions für Compliance. Nutzen Sie Workload Profiles für Production (dedizierte Hardware), Consumption für Dev/Test.
Scaling-Regeln strategisch konfigurieren
Kombinieren Sie HTTP-Scaling mit KEDA-Event-Scaling. Beispiel: Frontend skaliert auf 1-20 Replicas basierend auf HTTP-Requests, Backend-Worker auf Queue-Länge. Setzen Sie minReplicas>0 für latency-kritische Apps, 0 für Cost-Optimierung. Nutzen Sie concurrency-Limits (z.B. max 10 Requests pro Replica) für resource-intensive Operations.
Revisions für Blue-Green und Canary
Deployen Sie neue Versionen als Revision mit 0% Traffic, testen Sie ausführlich, dann Traffic Split 10/90. Bei Erfolg schrittweise auf 100%. Bei Fehlern sofortiger Rollback durch Traffic-Umschaltung. Automatisieren Sie über GitHub Actions: Deploy new revision → Health Check → Traffic Switch → Cleanup old revisions.
Observability mit Application Insights
Aktivieren Sie Application Insights für jede Container App. Nutzen Sie Structured Logging (JSON) für bessere Query-Möglichkeiten. Definieren Sie Custom Metrics für Business-KPIs (Orders/Minute, Processing-Time). Erstellen Sie Alerts für Anomalien (Error-Rate >1%, Latency >500ms). Dashboards mit Azure Workbooks für Stakeholder.
Secrets-Management mit Key Vault
Speichern Sie niemals Secrets direkt in Container Apps. Referenzieren Sie Azure Key Vault via Managed Identity. Container Apps lädt Secrets beim Start, aktualisiert bei Revision-Updates. Rotation von Secrets ohne Code-Änderung. Audit-Logs in Key Vault für Compliance.
Kostenoptimierung
Nutzen Sie scale-to-zero für Dev/Test und sporadische Workloads. Reservierte Kapazität (Savings Plans) für Production-Baseline. Monitoren Sie Kosten pro Container App via Cost Management Tags. Rightsizing: Viele kleine Replicas statt wenige große für bessere Granularität. Dedicated Workload Profiles nur wenn nötig (GPU, große Memory-Anforderungen).
Azure Container Apps vs. Alternativen
Bei der Wahl einer Container-Plattform stellt sich oft die Frage nach Alternativen. Azure Container Apps konkurriert mit vergleichbaren Services anderer Cloud-Provider:
- AWS: App Runner
- Google Cloud: Cloud Run
AWS App Runner bietet ähnliche Serverless-Container-Features, aber ohne Dapr-Integration und weniger KEDA-Scaler. Google Cloud Run ist sehr ähnlich zu Container Apps, mit starker Fokus auf HTTP-Workloads. Container Apps punktet durch umfassende KEDA-Integration (20+ Scaler), native Dapr-Support und nahtlose Azure-Ökosystem-Integration (VNET, Key Vault, Managed Identity).
Integration mit innFactory
Als Microsoft Solutions Partner unterstützt innFactory Sie bei der Migration und Optimierung von Container Apps. Wir helfen bei Architektur-Design, Dapr-Implementierung, KEDA-Scaling und Multi-Region-Deployments.
Kontaktieren Sie uns für eine unverbindliche Beratung zu Azure Container Apps und Container-Modernisierung.
Verfügbare Varianten & Optionen
Consumption
- Serverless Pay-as-you-go
- Scale-to-zero
- Keine Cluster-Verwaltung
- Cold-Start bei scale-to-zero
- Shared Infrastructure
Dedicated (Workload Profiles)
- Dedizierte Hardware
- GPU-Support
- Keine Noisy-Neighbor-Probleme
- Höhere Kosten
- Mindest-Kapazität erforderlich
Typische Anwendungsfälle
Technische Spezifikationen
Häufig gestellte Fragen
Wann sollte ich Container Apps statt AKS oder App Service wählen?
Container Apps eignet sich für Microservices ohne Kubernetes-Overhead. Wenn Sie Kubernetes-Features wie Custom CRDs, komplexe Networking oder Multi-Tenancy brauchen, wählen Sie AKS. Für monolithische Web-Apps ohne Container ist App Service oft einfacher. Container Apps ist der Sweet Spot für containerisierte Microservices mit Event-Driven Scaling.
Wie funktioniert das Pricing genau?
Sie zahlen pro vCPU-Sekunde (ca. 0,000012 Euro) und Memory-GB-Sekunde (ca. 0,0000014 Euro) während Container laufen. Plus Requests (erste 2 Millionen kostenlos, dann 0,35 Euro/Million). Scale-to-zero bedeutet 0 Kosten bei Inaktivität. Dedicated Workload Profiles haben Mindestkosten für reservierte Kapazität.
Was ist der Unterschied zu Azure Kubernetes Service (AKS)?
Container Apps ist serverless, AKS ist managed Kubernetes. Container Apps abstrahiert Cluster-Management, Scaling und Networking vollständig. AKS bietet volle Kubernetes-Kontrolle mit Komplexität. Container Apps nutzt intern Kubernetes+KEDA, ohne dass Sie YAML schreiben oder Nodes verwalten. Wählen Sie Container Apps für Einfachheit, AKS für Kontrolle.
Kann ich scale-to-zero deaktivieren?
Ja, setzen Sie minReplicas auf mindestens 1. Dies verhindert Cold Starts, kostet aber auch bei Inaktivität. Für Production-Workloads mit latency-kritischen Anforderungen empfohlen. Alternativ: Warmup-Requests oder dedicated Workload Profiles für garantierte Kapazität.
Wie funktioniert Dapr-Integration?
Dapr (Distributed Application Runtime) ist direkt integriert. Aktivieren Sie Dapr pro Container App, nutzen Sie Building Blocks wie Service Invocation, Pub/Sub, State Management, Secrets. Container Apps verwaltet Dapr-Sidecars automatisch. Ideal für Microservices-Patterns ohne eigene Service-Mesh-Implementierung.
Unterstützt Container Apps Multi-Region-Deployments?
Ja, deployen Sie Container Apps in mehrere Regionen und nutzen Sie Azure Front Door für globales Load Balancing. Jede Region ist eigenständig, Sie müssen State über Cosmos DB oder Redis synchronisieren. Kein automatisches Multi-Region-Failover, aber einfach über IaC zu orchestrieren.
Wie manage ich Secrets und Umgebungsvariablen?
Secrets werden verschlüsselt im Container App Environment gespeichert oder aus Azure Key Vault referenziert (via Managed Identity). Umgebungsvariablen können aus Secrets, Key Vault oder direkt definiert werden. Revisions erlauben sichere Updates ohne Downtime.
Was sind Revisions und Traffic Splitting?
Jedes Update erstellt eine neue Revision. Sie können mehrere Revisions parallel betreiben und Traffic prozentual verteilen (z.B. 90% auf v1, 10% auf v2). Ideal für Blue-Green-Deployments, Canary-Releases oder A/B-Testing. Rollback durch Traffic-Umschaltung ohne neues Deployment.
