Microservice-Entwicklung leicht gemacht - Azure Container Apps

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.

Autoren: Yu Li & Weili Gao

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.

Microservice-Entwicklung ist komplex

Welche Herausforderungen bei der Microservice-Entwicklung haben wir bei unseren Kunden angetroffen?

  • Herausforderung 1: Grosser Engineering- und Betriebsaufwand für Kubernetes
    In Applikationen mit Microservices wird heute in den allermeisten Fällen Kubernetes zur Container-Orchestrierung einsetzt. Der professionelle Betrieb von Kubernetes ist jedoch aufwändig und benötigt das Know-how von Experten zum Upgrade, zur Skalierung und zum Troubleshooting von Kubernetes und der unterliegenden Infrastruktur (z.B. Cluster-Upgrades, Node-Image-Upgrades etc.).

    Häufig verbringen Entwickler viel Zeit mit Kubernetes-Engineering und -Betrieb. Dies jedoch benötigt Ressourcen in den Dev-Teams, welche stattdessen in die Entwicklung der eigentlichen Applikation hätten investiert werden können. Der Fokus auf das eigentliche Ziel, nämlich der geschäftliche Nutzen, geht dadurch verloren.
     
  • Herausforderung 2: Komplexität von Microservices
    Bei Microservice-Architekturen handelt es sich um Software-Lösungen bestehend aus einer Vielzahl von verteilten Komponenten und Systemen. Microservices haben sehr viele Vorteile gegenüber herkömmlichen Architekturen wie z.B. Monolithen (besonders in der Cloud), bringen aber auch hohe Komplexität in den Bereichen Service Invocation, Security, Error Handling, State Management, Monitoring und Logging mit sich.

    Diese Aspekte im Microservice-Code sind schwierig zu bewältigen und benötigen viele Ressourcen und Erfahrung. Noch komplexer wird es, wenn in der Applikation verschiedene Programmiersprachen, Frameworks und Produkte verwendet werden (z.B. aufgrund von Anforderungen oder Entwickler-Skillsets), da so der Code in vielen verschiedenen Varianten geschrieben und unterhalten werden muss.
     
  • Herausforderung 3: Event-driven Autoscaling von Microservices
    Elastizität bzw. automatische Skalierung ist ein wichtiges Thema für Applikationen in der Cloud, um Lastspitzen verarbeiten zu können und kosteneffizient zu sein. Kubernetes bietet dazu verschiedene Lösungen zur horizontalen respektive vertikalen Auto-Skalierung von Pods und Nodes an (HPA/VPA/CA). Diese Autoscalers skalieren anhand von CPU/Memory-Verbrauchsdaten aus dem Kubernetes Metric Server.

    Microservices, welche event-getrieben Messages aus einem Service Bus oder Kafka verarbeiten, können jedoch nicht einfach nach Hardware-Metriken skaliert werden. Auch können die Nodes und Pods nicht ab Null skaliert werden, sodass selbst bei Nichtgebrauch gewisse Kosten anfallen. Es wird eine anspruchsvollere Lösung für die Skalierung benötigt, welche Kubernetes nicht out-of-the-Box anbietet.

Azure Container Apps zur Rettung

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).

Dapr.png
Bild 1: Beispielapplikation mit Dapr[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.

Dapr_2.png
Bild 2: Dapr Building Blocks

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.

Kubernetes Event-driven Autoscaling (KEDA)

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).

Fazit - Vielversprechendes Produkt zur Vereinfachung der Microservice-Entwicklung

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.

Quellen

[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

Deine ipt Experten

Wir freuen uns auf Deine Kontaktaufnahme