Microservices mit Dapr
Microservices sind ein Architekturmuster, bei dem eine komplexe Anwendung in einzelne Microservices geschnitten und aufgeteilt wird. Jeder Microservice erfüllt eine spezifische Aufgabe und kann einzeln entwickelt, getestet und deployt werden. Eine dementsprechend aufgebaute Software-Architektur, ermöglicht das einfache Ersetzen und Erweitern einzelner Microservices und bietet Vorteile betreffend Flexibilität, Skalierbarkeit und Resilienz. Diese Vorteile werden jedoch unter anderem mit einer höheren Komplexität, z.B. beim deployen, bei der Kommunikation zwischen den Services, der Datenhaltung und der Fehlersuche erkauft. Bei vielen dieser zusätzlichen Komplexitäten kann Dapr mit seinen Building Blocks helfen.
Dapr steht für «Distributed Application Runtime» und ist ein Projekt der Cloud Native Computing Foundation (CNCF).
Man kann sich Dapr als «Framework» für Microservices vorstellen, das als Sidecar Pattern umgesetzt ist. Es bietet für viele der gängigen Herausforderungen Building Blocks an.
Für GO, Node, .Net, Python, Java, C++, PHP und Rust gibt es ein SDK, es kann aber mit jeder Sprache verwendet werden die Http oder GRPC unterstützt.
Wir haben Dapr bereits in mehreren Projekten erfolgreich eingesetzt. Als Beispiel möchte ich den Einsatz im Projekt «Coinless MVP» aufzeigen, welches in einem vorherigen Blogbeitrag von uns vorgestellt wurde. Coinless ist ein Technologie Demonstrator Projekt, das den Umbau von bestehenden Münzautomaten auf bargeldlosen Betrieb via Handy ermöglicht.
Nebenstehend eine vereinfachte Übersicht über die beteiligten Microservices und Applikationen. In dieser C4 Container Grafik sind die Microservices als Hexagon gezeichnet und die Fremdsysteme wurden einfachheitshalber weggelassen.
Dapr stellt «Building Blocks» für viele der gängigen Problemstellungen bei Microservice Architekturen zur Verfügung.
Beim Coinless MVP haben wir folgende Dapr Building Blocks verwendet:
Service-to-service Invocation
«Service-to-service Invocation» ermöglicht die zuverlässige und sichere Kommunikation zwischen den Endpunkten der Microservices (HTTP oder gRPC). Wenn mehrere Instanzen des Microservices laufen, wird ein Loadbalancing mit Round Robin durchgeführt. Es werden Metriken und Traces für die Observability erfasst. Retries und Zugriffskontrolle können konfiguriert werden.
Wir haben den Building Block verwendet, um beim API-Gateway und beim Aggregator auf die einzelnen Microservices zu verbinden.
State Management
Der State Management Building Block (State Store) bietet einen Key/Value Store, um Microservices die einfache Möglichkeit zu geben Zustände auch über mehrere Instanzen sicher zu speichern und zu verwenden. Der Building Block lässt sich entsprechend gut zu den Bedürfnissen konfigurieren:
- Concurrency (ETags)
- Consistency (Strong, Eventual)
- TTL (Time To Live)
- Zugriffsbeschränkungen und vieles mehr…
Der Building Block unterstützt mehrere Stores. Für das Coinless Projekt haben wir Redis als Store gewählt. Wir verwenden es in unserer Applikation unter andere, um die unterschiedlichen Zustände der Tickets zu verwalten.
Publish and Subscribe
Der Pub/Sub Building Block ermöglicht den Microservices die Kommunikation über Messages.
Dies wird in unserer Applikation z.B. zum Lösen von Tickets verwendet. Die Message wird in einer nächsten Version benötigt, um Auswertungen über die Ticketverkäufe zu tätigen.
Dapr unterstützt die gängigen Anbieter wie bspw. RabittMQ, Kafka, etc.
Observability
Observability ist in verteilten Applikationen wichtig, um Probleme und Fehler zu finden, da bei einer Aktion in der Regel mehrere Komponenten betroffen sind. Auf dem Bild unten sehen wir die Distributed Traces, die für den Vorgang des Ticket Lösens erzeugt wurden. Wenn eine Aktion länger dauert als erwartet, oder sogar ein Fehler auftritt, kann der Verursacher so schnell gefunden werden.
Secrets
Dapr stellt einen Secrets Building Block bereit, welcher sich in alle gängigen Secret-Stores wie beispielsweise AWS Secrets Manager oder Kubernetes integrieren lässt. Microservices können nun den Building Block verwenden, um beispielsweise die Zugangsdaten für einen Datenbank Zugriff abzufragen.
Fazit
Aus unserer Erfahrung ist Dapr ein solides hilfreiches Framework, um Microservice-Lösungen umzusetzen. Es stellt bewährte Building Blocks zur Verfügung, um die Komplexität und den zusätzlichen Aufwand von Microservices zu reduzieren.
Die von Dapr erzeugten Distributed Traces helfen erheblich bei der Lokalisierung von Problemen.
Ein weiterer Vorteil ist die grosse Flexibilität beim Einsatz. Dapr läuft sowohl mit Docker lokal, mit Kubernetes bei einem beliebigen Cloudanbieter oder On-Premises sowie Serverless in Azure Container Apps. Die Building Blocks können entsprechend konfiguriert werden, so dass z.B. zu Beginn der Entwicklung Redis als Store verwendet werden kann und man zu einem späteren Zeitpunkt bei Bedarf mit wenig Aufwand auf eine alternative Umsetzung des Building Blocks wechseln kann.
Dapr wird sehr aktiv weiterentwickelt, es kommen laufend neue Funktionalitäten (Building Blocks) ins Framework, sowie Erweiterungen / Optimierungen der bestehenden Building Blocks.
Folgende Punkte müssen bei einem Einsatz von Dapr beachtet werden:
- Dapr ist ein Sidecar Pattern, es findet also zusätzliche Kommunikation statt, die Verzögerung ist verschwindend gering und wird in den meisten Fällen nicht relevant sein, ist aber trotzdem vorhanden.
- Die Building Blocks von Dapr legen grossen Wert auf die Austauschbarkeit der Implementationen, wenn also z.B. ein sehr spezifisches Feature von Redis benötigt wird, steht es via Dapr evtl. nicht zur Verfügung. Das sollte man rechtzeitig in der Dapr Dokumentation überprüfen.