Starten statt orchestrieren

von Philip Lorenz

Containerisierte Anwendungen ohne Kubernetes-Overhead? Azure Container Apps ermöglicht genau das: serverlose Container mit automatischer Skalierung, klarer Kostenstruktur und einfacher Bereitstellung. Unser Workshop zeigt, wann Azure Container Apps – kurz ACA – eine echte Alternative zu Azure Kubernetes Service ist, wo Grenzen liegen und wie Sie mit CLI, Portal und Terraform eigene Anwendungen produktiv umsetzen.

Container gelten längst als Standard moderner Softwarebereitstellung. Doch mit Kubernetes kam für viele Teams auch ein erheblicher Mehraufwand: Ein eigener Cluster erfordert Pflege von Nodes, Upgrades, Netzwerkregeln und Monitoring. Für große Unternehmen mit dedizierten Plattform-Teams mag das sinnvoll sein – für kleinere IT-Teams ist es oft ein unnötiger Kraftakt.

Azure Container Apps (ACA) [1] schafft hier Abhilfe. Der Dienst nutzt Container-Technologien und Automatisierung, ohne selbst einen Kubernetes-Cluster zu betreiben. Microsoft abstrahiert den Cluster-Betrieb und stellt eine serverlose Plattform bereit, die dynamisch skaliert und dabei Kosten transparent hält. Ihre Anwendungen laufen in Containern – Sie kümmern sich nur um den Code, nicht um die Infrastruktur.

Besonders interessant ist ACA für Microservices, APIs oder ereignisgesteuerte Anwendungen. Workloads lassen sich bei Bedarf auf hunderte Instanzen hochskalieren – und bei geringer Last automatisch wieder auf null herunterfahren. So entsteht ein Cloudmodell, das Flexibilität mit Effizienz verbindet.

Vom Container zum Dienst

Azure Container Apps ist eine vollständig verwaltete Plattform zum Ausführen containerisierter Anwendungen – ganz ohne eigenen Cluster-Betrieb. Sie stellen lediglich Ihr Container-Image bereit, während Azure Skalierung, Orchestrierung und Infrastruktur automatisch übernimmt. Typische Einsatzfelder sind Microservices, Web-APIs, Batchjobs und ereignisgesteuerte Workloads. ACA kann bei geringer Last auf null Instanzen herunterfahren und bei Bedarf innerhalb weniger Sekunden wieder skalieren. Dadurch eignet sich der Dienst ideal für Anwendungen mit stark schwankendem oder schwer vorhersehbarem Ressourcenbedarf.

Die Plattform integriert etablierte Werkzeuge aus dem Kubernetes-Ökosystem: KEDA sorgt für ereignisgesteuerte Skalierung, Dapr vereinfacht die Kommunikation zwischen Microservices. Netzwerkfunktionen wie internes Service-Discovery und Public-Ingress sind ebenfalls standardmäßig vorhanden.

Kurz gesagt: Azure Container Apps ermöglicht produktive Container-Work-loads, ohne dass Sie einen Kubernetes-Cluster bereitstellen oder verwalten müssen.

Wann ACA – und wann Kubernetes

Ob Sie Azure Kubernetes Service (AKS) – Microsofts gemanagte Kubernetes-Plattform – oder Azure Container Apps einsetzen, hängt von Ihren Anforderungen und Ihrer Organisation ab. Beide basieren auf Containern und Kubernetes-Technologie; ACA abstrahiert den Cluster-Betrieb, AKS bietet volle Kontrolle über das Kubernetes-API.

Ein Start-up, das ein kleines API entwickeln und schnell in den Markt bringen möchte, profitiert klar von ACA. Hier zählen Einfachheit, Geschwindigkeit und eine transparente Kostenstruktur. Das Team muss sich weder um Cluster-Updates, Loadbalancer noch um Netzwerk-Policies kümmern – das Container-Image genügt, Azure übernimmt den Rest. Der Einstieg mit ACA schließt einen späteren Umstieg auf AKS nicht aus: Sie können sofort produktiv starten und bei wachsendem Bedarf in die volle Kubernetes-Welt wechseln.

Ein internationaler Konzern mit hunderten Microservices und strengen Governance-Vorgaben fährt dagegen besser mit Kubernetes. In AKS haben Sie Zugriff auf das vollständige Kubernetes-API, können eigene Operatoren einsetzen, Custom Resource Definitions verwalten und tiefgreifende Integrationen mit internen Plattformen umsetzen. Der Preis für diese Freiheit ist eine deutlich höhere Komplexität – und der Bedarf an spezialisierten Plattform-Teams.

Zwischen diesen Extremen gibt es viele Zwischenstufen. ACA eignet sich überall dort, wo Sie einzelne Workloads isoliert und flexibel betreiben möchten – etwa APIs, Worker oder Event-Handler. Kubernetes bleibt die richtige Wahl, wenn Sie eine zentrale, hochintegrierte Container-Plattform aufbauen wollen, die maximale Kontrolle und Governance erfordert.

Architektur und Funktionsweise

Azure Container Apps basiert technisch auf Kubernetes, nimmt Ihnen aber die komplette Verwaltung der Cluster-Infrastruktur ab. Sie profitieren von den Vorteilen des Kubernetes-Ökosystems, ohne Nodes, Upgrades oder Control Planes selbst betreiben zu müssen – Ihr Fokus liegt allein auf den Anwendungen.

Zentrale Einheit ist das Container-Apps-Environment, der logische Rahmen für Ihre Container-Workloads. Darin lassen sich mehrere Apps betreiben, etwa ein Frontend, ein Backend und ein Worker. Jede App läuft isoliert, kann aber über die integrierte Service-Discovery mit anderen Diensten derselben Umgebung kommunizieren. Das vereinfacht Netzwerkkonfiguration und Lastverteilung erheblich.

Ein wichtiger Baustein ist die Wahl des Workload-Profils:

- Consumption-Profil: Sie zahlen nur, wenn Container laufen. Apps können auf null Instanzen herunterskalieren – ideal für APIs oder Event-Handler, die nicht dauerhaft aktiv sein müssen.

- Dedicated-Profil: Hier reservieren Sie feste Ressourcen (CPU und RAM). Dieses Modell eignet sich für latenzkritische Workloads, die jederzeit verfügbar sein sollen. Beide Profile lassen sich kombinieren, um Kosten und Performance optimal auszubalancieren.

Bild 1 zeigt eine typische Umgebung: Der externe Zugriff erfolgt über ein Ingress, das Anfragen von außen in die Container-App-Umgebung leitet. Innerhalb kommunizieren die Apps direkt miteinander – etwa ein Frontend mit einem Backend. Über Revisions verwalten Sie verschiedene Versionen einer App. Neue Deployments erzeugen automatisch eine Revision, die parallel zur alten läuft. Den Datenverkehr können Sie flexibel aufteilen, beispielsweise 70 Prozent auf Revision 1 und 30 Prozent auf Revision 2. So lassen sich Blue/Green-Deployments oder A/B-Tests mit minimalem Aufwand umsetzen.

Ein weiterer Kernpunkt ist die Skalierung. ACA nutzt dafür KEDA (Kubernetes Event Driven Autoscaler), das Workloads auf Basis von Ereignissen, Metriken oder Queue-Längen automatisch anpasst. Neben CPU- und Speichernutzung können externe Trigger wie Azure Service Bus, Kafka oder HTTP-Anfragen zum Einsatz kommen. Ihre Anwendungen reagieren damit dynamisch auf wechselnde Lasten, bis hin zum vollständigen Stillstand bei Inaktivität ("Scale-to-zero").

Für den Betrieb stehen integrierte Monitoring- und Observability-Funktionen bereit. Container-Apps lassen sich direkt an Azure Log Analytics anbinden, wo Logs, Metriken und Ereignisse zentral erfasst und ausgewertet werden. So behalten Sie auch bei mehreren aktiven Revisions und gemischten Workload-Profilen jederzeit den Überblick über Stabilität und Performance.

Zusammengefasst vereint ACA die wichtigsten Kubernetes-Konzepte – Skalierung, Trafficsteuerung und Servicekommunikation – in einer Plattform, die sich ohne tiefgehende Cluster-Kenntnisse produktiv einsetzen lässt.

Microservices entwickeln mit Dapr

Azure Container Apps bietet mit Dapr (Distributed Application Runtime) ein Werkzeug, um Microservices leichter zu entwickeln und zu verbinden. Dapr ist ein Open-Source-Framework, das typische Herausforderungen in verteilten Anwendungen adressiert – etwa Kommunikation, Ereignissteuerung oder Zustandsverwaltung.

Dapr stellt dazu verschiedene Building-Blocks bereit, die Sie direkt nutzen können, ohne eigene Implementierungen zu schreiben:

- Service Invocation: Aufruf anderer Dienste über standardisierte HTTP- oder gRPC-Schnittstellen.

- Pub/Sub-Messaging: Ereignisbasierte Kommunikation zwischen Services mit gängigen Message-Brokern wie Kafka oder Azure Service Bus.

- State-Management: Persistente Speicherung von Zuständen, zum Beispiel in Cosmos DB oder Redis, ohne dass Sie selbst Datenzugriffe programmieren müssen.

- Bindings: Einfache Anbindung externer Systeme wie Datenbanken, Storage oder Event-Plattformen über standardisierte Schnittstellen.

In Azure Container Apps aktivieren Sie Dapr direkt über das Portal oder per Template. Jeder Container-App lassen sich Dapr-Komponenten zuordnen, die automatisch als Sidecar-Container bereitstehen. Entwickler greifen anschließend über einheitliche Endpunkte darauf zu, ohne Implementierungsdetails kennen zu müssen.

Ein praktisches Beispiel: Anstatt im Code manuell HTTP-Requests an eine andere App zu schreiben, können Sie einfach "http://localhost:<Dapr-Port>/v1.0/invoke/orderservice/method/create" aufrufen. Dapr übernimmt Routing, Service-Discovery und Fehlerbehandlung. So sinkt die Komplexität im Anwendungscode deutlich.

Gerade in größeren Architekturen zahlt sich dieser Ansatz aus: weniger Boilerplate-Code, geringerer Integrationsaufwand und höhere Portabilität der Services. Da Dapr quelloffen ist, bleiben Sie unabhängig von Azure und können dieselben Konzepte auch problemlos in anderen Kubernetes- oder Container-Umgebungen einsetzen.

Preismodelle und Sparpotenzial

Azure Container Apps rechnet anders ab als klassische Kubernetes-Cluster: Sie bezahlen nicht für Nodes oder Control-Planes, sondern nur für tatsächlich genutzte Ressourcen. Dadurch bleibt die Kostenstruktur deutlich transparenter als bei AKS, wo bereits der laufende Cluster-Betrieb Grundkosten verursacht.

Azure bietet dafür drei Hauptmodelle und eine Sparoption:

- Free-Tier: Die ersten 180.000 vCPU-Sekunden, 360.000 GiB-Sekunden und zwei Millionen Requests pro Monat sind kostenlos. Eine GiB-Sekunde entspricht dabei einem Gibibyte RAM, das eine Sekunde lang genutzt wird.

- Consumption-Plan: Sie zahlen nur, wenn Container aktiv sind. Wird eine Anwendung auf null Instanzen skaliert, entstehen keine Kosten. Abgerechnet wird sekundengenau nach vCPU-, RAM- und Request-Verbrauch.

- Dedicated-Plan: Reservierte Ressourcen (CPU und RAM) werden unabhängig von der tatsächlichen Nutzung berechnet. Ideal für Workloads, die dauerhaft verfügbar sein müssen oder eine planbare Auslastung erfordern.

- Sparpläne: Wer sich für ein festes Stundenbudget (ein oder drei Jahre) verpflichtet, kann die Preise im Dedicated-Plan spürbar senken.

Ein einfaches Beispiel verdeutlicht die Unterschiede (alle Werte als Richtwerte):

- Szenario A – API im Consumption-Plan: Eine Container-App (0,5 vCPU, 1 GiB RAM), 100.000 Requests pro Monat, durchschnittlich 500 ms Laufzeit kosten circa 2 bis 3 Euro pro Monat.

- Szenario B – Dauerbetrieb im Dedicated-Plan: Eine Container-App (1 vCPU, 2 GiB RAM), durchgehend aktiv (730 Stunden pro Monat) kostet rund 40 bis 50 Euro pro Monat.

Der Vergleich zeigt: Für unregelmäßige oder schwankende Workloads ist der Consumption-Plan besonders günstig. Bei dauerhaft laufenden Anwendungen bietet der Dedicated-Plan mehr Sicherheit. Mit Sparplänen lassen sich die Gesamtkosten zusätzlich reduzieren.

Ein klarer Vorteil gegenüber AKS: Sie müssen keine separaten Cluster-Kosten einplanen und profitieren von höherer Kostentransparenz. Dennoch sollten Sie die Nutzung regelmäßig prüfen – dauerhaft aktive Container im Consumption-Plan können schnell für unerwartete Kosten sorgen.

Wo Azure Container Apps an Grenzen stoßen

So komfortabel Azure Container Apps im Betrieb auch ist – ganz ohne Einschränkungen kommt die Plattform nicht aus. Einige Punkte sollten Sie vor der Einführung kennen, um spätere Überraschungen zu vermeiden.

Zunächst betrifft das die Unterstützung von Containern: ACA führt ausschließlich Linux-basierte Images auf amd64-Architektur aus. Windows-Container oder privilegierte Container mit Hostzugriff sind nicht erlaubt. Workloads, die tief ins Betriebssystem eingreifen oder spezielle Kernelerweiterungen erfordern, lassen sich damit nicht betreiben.

Auch bei der Container-Größe gelten feste Grenzen. Im Consumption-Plan können Images pro Replica maximal 8 GByte groß sein. Größere Images – etwa bei umfangreichen Frameworks oder integrierten Datensätzen – erfordern deshalb zweingend den Dedicated-Plan.

Ein weiterer Aspekt sind sogenannte Cold-Starts: Wenn eine Anwendung im Consumption-Plan vollständig auf null Instanzen herunterskaliert und anschließend durch eingehende Requests reaktiviert wird, entsteht eine kurze Startverzögerung. Für latenzkritische APIs oder interaktive Anwendungen kann das spürbar sein.

Darüber hinaus nutzt ACA ein Revisionskonzept. Jede Änderung an einer App erzeugt automatisch eine neue Revision – praktisch für Rollbacks oder Blue/Green-Deployments, aber mit der Einschränkung, dass höchstens 100 inaktive Revisionen gespeichert werden. Wer häufig neue Versionen deployt, sollte also regelmäßig aufräumen.

Zuletzt ist zu beachten, dass ACA bewusst eine Abstraktionsebene über Kubernetes einzieht. Ein direkter Zugriff auf das Kubernetes-API, eigene Operatoren oder Custom-Resource-Definitions ist nicht möglich. Für die meisten Einsatzszenarien reicht das aus – bei komplexen Integrationen oder plattformweiten Automatisierungen bietet AKS allerdings die größere Flexibilität.

Insgesamt gilt: Azure Container Apps deckt viele moderne Anwendungsszenarien ab, stößt aber an klare Grenzen, sobald Windows-Workloads, besonders große Container oder tiefe Kubernetes-Integrationen gefragt sind. Wer diese Rahmenbedingungen kennt, kann die Plattform gezielt und ohne böse Überraschungen einsetzen.

Praxisbeispiel: Erstellen einer Container-App

Der Einstieg in Azure Container Apps gelingt am einfachsten über das Azure CLI. Mit wenigen Befehlen erstellen Sie Ressourcengruppe, Umgebung und die eigentliche Container-App. Ein Log-Analytics-Workspace wird dabei automatisch mit angelegt.

Das folgende Beispiel zeigt, wie Sie eine Container-App aus einem öffentlichen Image bereitstellen, die über HTTPS erreichbar ist:

Nach wenigen Minuten ist die Anwendung erreichbar. Im Azure-Portal sehen Sie anschließend Details zu Ingress-Einstellungen, Container-Definitionen, Revisionsverlauf und Metriken.

Für erste Tests reicht das CLI völlig aus. Doch sobald Sie mit mehreren Umgebungen – etwa Entwicklung, Staging und Produktion – arbeiten oder Workloads reproduzierbar bereitstellen wollen, führt an Infrastructure-as-Code (IaC) kein Weg vorbei. Hier kommt Terraform ins Spiel. Damit beschreiben Sie Ihre Infrastruktur deklarativ und sorgen dafür, dass sie konsistent und versionierbar bereitgestellt wird. Änderungen sind jederzeit nachvollziehbar und lassen sich bei Bedarf sauber zurückrollen. Gerade im produktiven Betrieb sollten Container-Apps immer über Code definiert werden. Ein Beispiel zeigt der Listing-Kasten.

Mit diesem Ansatz stellen Sie sicher, dass jede Umgebung identisch aufgebaut wird – unabhängig davon, ob Sie lokal entwickeln oder in Produktion deployen. Terraform ermöglicht es Ihnen außerdem, Änderungen nachvollziehbar einzuspielen und Fehler leichter zurückzurollen.

Best Practices und Sicherheit

Der produktive Betrieb von Azure Container Apps erfordert mehr als nur das Starten von Containern. Damit Anwendungen stabil, sicher und kosteneffizient laufen, sollten Sie einige bewährte Vorgehensweisen beachten. Ein zentraler Punkt ist der Umgang mit Secrets. Zugangsdaten für Datenbanken oder Container-Registries gehören niemals in Images oder Terraform-Dateien, sondern werden in Azure Container Apps als Secrets hinterlegt. Diese lassen sich direkt in der App konfigurieren oder sicher über Azure Key Vault einbinden. In Kombination mit Managed Identities entfällt sogar die Notwendigkeit, Passwörter selbst zu verwalten. Dabei gilt das Minimalprinzip: Jede Identität erhält nur die Rollen, die sie wirklich benötigt.

Auch beim Netzwerkdesign ist Planung entscheidend. Standardmäßig sind Container-Apps über ein externes HTTPS-Ingress erreichbar. Für interne Kommunikation empfiehlt sich die Nutzung der integrierten Service-Discovery oder die Anbindung an ein Virtual Network (VNET). So lassen sich Apps in bestehende Unternehmensnetzwerke integrieren und über Firewalls oder Private-Endpoints absichern.

Für den laufenden Betrieb ist Observability unerlässlich. Azure Container Apps lässt sich mit Azure Log Analytics verbinden, um Logs, Metriken und Skalierungsereignisse zentral zu überwachen. Richten Sie zusätzlich Alerts ein, um bei Fehlern oder ungewöhnlichem Ressourcenverbrauch sofort informiert zu werden. Ein Beispiel: Überschreitet die Fehlerrate Ihrer Anwendung fünf Prozent, kann automatisch eine Benachrichtigung an das Betriebsteam gesendet werden. Ebenso lassen sich Warnschwellen für CPU- oder Speicherauslastung definieren, um Engpässe frühzeitig zu erkennen.

Auch die Deployment-Strategie verdient Aufmerksamkeit. Nutzen Sie Revisions, um neue Versionen parallel bereitzustellen und den Datenverkehr schrittweise umzuleiten. Blue/Green- oder Canary-Deployments sind mit Azure Container Apps direkt möglich und reduzieren das Risiko bei Updates. Wichtig ist, Deployments konsequent über Infrastructure-as-Code zu steuern, um jederzeit den exakten Stand der Umgebung reproduzieren zu können.

Darüber hinaus spielt Governance eine zentrale Rolle. Mit Role Based Access Control (RBAC) steuern Sie exakt, wer Container-Apps bereitstellen oder ändern darf. Tags helfen, Kosten transparent Projekten oder Teams zuzuordnen. Über Azure Policy lassen sich Vorgaben wie "nur Images aus genehmigten Registries" oder "VNET-Integration ist verpflichtend" automatisch prüfen und durchsetzen.

Nicht zuletzt sollten Sie die Ressourcenzuteilung sorgfältig wählen. Im Consumption-Profil zahlen Sie ausschließlich für aktive Workloads – ideal für APIs oder Event-Handler. Latenzempfindliche Anwendungen profitieren dagegen vom Dedicated-Plan mit passenden Workload-Profilen. Vermeiden Sie außerdem die Nutzung statischer Image-Tags wie "latest". Verwenden Sie stattdessen eindeutige Versionskennzeichnungen, etwa Build-Nummern oder Git-Hashes. So bleiben Ihre Deployments konsistent und jederzeit nachvollziehbar.

Fazit

Azure Container Apps bietet einen unkomplizierten Einstieg in die containerisierte Anwendungswelt. Sie ersparen den Aufwand für den Betrieb eigener Kubernetes-Cluster, skalieren automatisch und ermöglichen eine transparente nutzungsbasierte Abrechnung. Für APIs, Microservices oder ereignisgesteuerte Workloads ist das häufig der pragmatischste Ansatz.

Dennoch ersetzt die Plattform kein vollwertiges Kubernetes-Setup: Wer maximale Kontrolle, erweiterte Integrationen und eigene Operatoren benötigt, bleibt bei AKS besser aufgehoben. In der Praxis ergänzen sich beide Ansätze ideal – Azure Container Apps für den schnellen, kosteneffizienten Start und AKS für komplexe, langfristig gewachsene Plattformen.

Mit integrierten Komponenten wie Dapr, KEDA und künftigem GPU-Support entwickelt sich Azure Container Apps zunehmend zu einer vielseitigen Option für moderne Cloudarchitekturen – leichtgewichtig, flexibel und bereit für produktive Szenarien.