Yu Li
Associate Partner
Mit Azure Container Apps können containerisierte Microservices entwickelt und betrieben werden, ohne dass sich Entwickler um die Administration eines Kubernetes-Clusters kümmern müssen. Gleichzeitig können Entwickler auf neue Features wie verbesserte Unterstützung für Microservice-Entwicklung oder Event-driven Autoscaling zurückgreifen, welche eine kürzere Time-to-Market und bessere Skalierbarkeit ermöglichen.
Moderne Applikationen bestehen häufig aus einer hohen Anzahl von Microservices, welche in Docker-Containern verpackt und deployed werden. Der Industriestandard zur Orchestrierung dieser Container ist Kubernetes. Ein sehr mächtiges System, welches komplex zu beherrschen, und betreiben ist. Ende 2021 hat Microsoft die Azure Container Apps vorgestellt. Sie ermöglichen es, dass Entwickler die vielen Vorzüge von Kubernetes geniessen können, ohne es selbst betreiben zu müssen. Wie genau damit die Microservice-Entwicklung vereinfacht wird und was für Herausforderungen damit gelöst werden, zeigen wir in diesem Blogbeitrag auf.
Welche Herausforderungen bei der Microservice-Entwicklung haben wir bei unseren Kunden angetroffen?
Serverless Kubernetes
Azure Container Apps (ACAs) sind eine Abstraktionsschicht über Kubernetes und machen es zu einem “Serverless” Produkt. Mit ACAs können containerisierte Microservices orchestriert werden, ohne dass sich Entwickler um den Betrieb von Kubernetes sorgen müssen - diese Verantwortung wird von Microsoft übernommen. Zudem unterstützen ACAs out-of-the-Box Open-Source-Lösungen wie Dapr oder KEDA, sodass Entwickler diese nicht selbst auf Kubernetes einrichten und betreiben müssen.
Einen Nachteil hat die Abstraktion in ACAs: Entwickler können keine eigenen Anpassungen an den unterliegenden Kubernetes-Cluster vornehmen, da sie nicht auf die Kubernetes APIs oder Nodes zugreifen können. So können z.B. keine zusätzlichen Add-Ons installiert oder die Disks mit eigenen Keys verschlüsselt werden (BYOK).
Distributed Application Runtime (Dapr)
Dapr ist ein Open-Source-Projekt mit dem Ziel, die Microservice-Entwicklung auf Kubernetes so einfach wie möglich zu gestalten. Die Dapr-Runtime stellt eine Abstraktionsschicht dar, welche in einem Sidecar-Container neben dem eigentlichen Microservice-Container im gleichen ACA betrieben wird (Bild 1).
Der Microservice-Container kommuniziert mit dem Dapr-Sidecar über Plattform-agnostische HTTP/gRPC APIs, um z.B. auf andere Services, State Stores oder Pub/Sub Brokers zuzugreifen. Diese APIs sind thematisch in sogenannte Building Blocks gruppiert (Bild 2), welche wiederum aus einzelnen Dapr Components bestehen.
Nachfolgend sollen zwei Beispiele beschrieben werden:
Beispiel 1: Service-to-Service Invocation ist ein häufiger Use Case bei Microservices. Durch Verwendung des Service Invocation Building Blocks übernimmt Dapr die Verantwortung für das Tracing, mTLS Authentisierung und Retry-Logik. Der Entwickler kann sich im eigentlichen Microservice auf die Implementierung der Business-Logik konzentrieren. Die Entwicklung wird dadurch beschleunigt und die Verantwortlichkeiten klar aufgeteilt.
Beispiel 2: Beim State Management geht es darum, den Zustand eines Microservices in einem State Store zu speichern und abzufragen. Dapr reduziert die Komplexität, indem es eine Produkt-agnostische API für den Microservice anbietet. In ACAs kann der Dapr State Store Component für verschiedene State Stores wie z.B. Redis oder Azure Storage konfiguriert werden. Bei einem Wechsel des State Stores muss der Code im Microservice nicht geändert werden, sondern nur die Konfiguration im Dapr State Store Component.
KEDA ist ein weiteres Open-Source-Projekt, welches von ACAs verwendet wird. Mit KEDA können ACAs ähnlich wie Serverless Functions basierend auf Events (wie z.B. veränderte Queue Length in Azure Service Bus oder Stream Lag in Kafka) ab Null skaliert werden, sodass nur bei tatsächlichem Bedarf ACAs hochgefahren werden und Kosten anfallen (On-Demand Compute und Pay-per-Use).
Die Skalierung ab Null wird mit KEDA ermöglicht, da im Vergleich mit herkömmlicher Hardware-Metriken-basierter Skalierung die Event-basierte Skalierung viel schneller und präziser auf geändertem Bedarf reagiert - es wird direkt auf die “Ursache” für die Skalierung reagiert (z.B. längere Queue) anstatt nur auf die “Symptome” (z.B. höherem CPU/Memory-Verbrauch).
ACAs sind ein “Serverless Kubernetes” Produkt von Azure mit der Value Proposition, die Komplexität bei der Entwicklung und dem Betrieb von Microservices so weit wie möglich zu reduzieren. Dies wird dadurch erreicht, dass Entwickler sich nicht mehr um den Betrieb von Kubernetes kümmern müssen und sich vollständig auf die Entwicklung der eigentlichen Applikation fokussieren können. Zudem bieten ACAs Out-of-the-Box-Unterstützung für Dapr und KEDA, welche zusätzlich die Microservice-Entwicklung und -Skalierung vereinfachen.
ACAs sind vor allem für Entwicklungsteams interessant welche nicht die Ressourcen oder das Know-how zum Betrieb von Kubernetes besitzen und keine speziellen Anpassungen an Kubernetes benötigen. ACAs eignen sich auch gut als Zwischenschritt für Teams auf dem Weg zum selbstbetriebenen Kubernetes. So können Entwickler bereits erste Erfahrungen mit Microservices sammeln, ohne sofort mit der ganzen Komplexität von Kubernetes konfrontiert zu werden.
Microsoft gab vor kurzem (24.05.2022) die General Availability von ACAs bekannt, so dass sie nun auch in Produktion eingesetzt werden können. Es lohnt sich, sich frühzeitig mit ACAs auseinander zu setzen und z.B. erste PoCs durchzuführen. Unserer Meinung nach bietet ACA interessante Lösungsansätze für moderne Software-Lösungen nach Microservice-Architekturen und adressiert wichtige Pain Points, welche wir oft auf unterschiedlichen Kundenprojekten antreffen.
[1] https://docs.microsoft.com/en-us/azure/container-apps/microservices-dapr?tabs=bash
[2] https://docs.dapr.io/concepts/overview/#microservice-building-blocks-for-cloud-and-edge
Wir freuen uns auf Deine Kontaktaufnahme