Best Practices zu Datenhaltung bei Microservices

Nutzung von Container-Technologie

Autor: Simon Flühmann

Bei der Umsetzung von Microservice Architekturen sollte konsequent auf Container Technologien gesetzt werden. Container bieten die nötige Isolation und ermöglichen ein unabhängiges Deployment von einzelnen Microservice-Instanzen. Die empfohlene Herangehensweise punkto Datenhaltung ist somit eng mit den Best Practices aus der Welt der Container Orchestrierung verknüpft.

Container und PaaS Infrastrukturen, wie z.B. Red Hat OpenShift, ermöglichen die Umsetzung diverser Lösungsansätze, um den verschieden Anforderungen von Microservice Applikationen gerecht zu werden. Microservices mit «Database per Service» lassen sich insbesondere mit OpenShift respektive Kubernetes sehr einfach umsetzen. Das Pods-Konzept von OpenShift sieht unabhängige Container mit der Geschäftslogik sowie der Persistenz-Lösung (z.B. MySQL) vor.

Verteilte Datenbanksysteme

Eine zentrale, shared Datenbank ist nicht unbedingt ein geeigneter Ansatz für Microservice Architekturen. In einem solchen Szenario empfiehlt sich der Einsatz von verteilten, dezentralisierten Datenbanksystemen (z.B. Cassandra ScyllaDB). Dabei wird jedem Microservice ein eigener Space zugewiesen, was de facto wieder dem Ansatz «Database per Service» entspricht. Somit könnte sich auch dieser Ansatz für die Datenhaltung bei Microservices qualifizieren.

Event-driven Data Management

Für die Umsetzung von Event-driven Microservice-Architekturen gibt es verschiedene Herangehensweisen. Frameworks wie Vert.X oder Lightbend Lagom bieten nützliche Hilfestellungen. Das Framework Lagom bringt beispielsweise Event-driven Data Management mit Event Sourcing oder eine Message Bus API bereits‚ «out-of-the-box» mit.

Aufgrund der hohen Komplexität und der grossen Divergenz zu herkömmlichen Architekturen, empfiehlt ipt die Nutzung von Event-driven Data Management nur bei Neuentwicklungen. Es sollten so wenige externe Abhängigkeiten, insbesondere nicht zu Legacy-Systemen, wie möglich vorhanden sein. Event-driven Architekturen eignen sich hauptsächlich für Anwendungen mit hohen Anforderungen an die Skalierbarkeit (z.B. Stream Processing oder High Volume Data).

Zur Umsetzung einer Event-driven Data Management Lösung eignet sich beispielsweise das Produkt Apache Kafka. Dieses ist jedoch nicht zur Langzeit-Speicherung von Geschäftsdaten gedacht. Hier empfiehlt sich als Ergänzung nach wie vor eine verteilte Datenbank wie beispielsweise Cassandra ScyllaDB, welche aus dem Event Stream abgefüllt werden kann.

Event Sourcing ist ein gut geeigneter Ansatz für die Datenhaltung bei Microservices. Zu beachten ist aber, dass Lösungen, die Event Sourcing beinhalten, eine steile Lernkurve voraussetzen. Aufgrund der ungewohnten und vielschichtigen Architektur werden solche Implementationen häufig als komplexer wahrgenommen.

Fazit

Es gibt verschiedene Ansätze, um die Herausforderungen zur Datenhaltung bei Microservices zu adressieren. Aus ipt-Sicht gibt es kein Patentrezept – je nach nicht-funktionalen Anforderungen muss die Lösungsarchitektur bezüglich Datenhaltung angepasst werden. In einem hochverteilten System, wie einer Microservice-basierten Applikation, muss immer abgewägt werden zwischen den Bedürfnissen des Business und technischen Limitationen. Je nach Einsatzzweck ist es sicher sinnvoll ein spezifisches Pattern zu wählen oder aber verschiedene Patterns miteinander zu kombinieren. Zentral ist, dass die eigesetzte Persistenz-Technologie genau auf den spezifischen Anwendungsfall des Microservice zugeschnitten ist.

Vor einer Transformation zu einer Microservice-Architektur sollte gründlich evaluiert werden, ob man sich dieses neuartige Architekturmuster nachhaltig aneignen will und die organisatorischen Voraussetzungen dazu gegeben sind. Produktorientierte Teams im DevOps-Modell sind die ideale Basis für die erfolgreiche Umsetzung einer Microservice Architektur.