Sind viele unabhängige Microservices effizient?
Mit Szenario 1 haben wir bereits eine sehr effiziente Variante für einen einzigen Microservice kennengelernt. Weshalb also nicht einfach ganz viele von diesen Microservices und den zugehörigen Teams bilden?
Problematik
In der Praxis zeigt sich, dass mit einer solchen Architektur von ganz vielen unabhängigen Microservices die folgenden Probleme auftreten:
- Nur wenige Features können voll autonom mit einem Team umgesetzt werden. Meistens werden doch immer auch noch fremde Daten benötigt, die nicht vom eigenen Microservice persistiert werden. Dies führt zu Abhängigkeiten zu teamfremden Microservices und damit zu Mehraufwand, Abstimmungsbedarf und Zeitverlust.
- Es besteht die Gefahr, dass dieselben Daten redundant in mehreren Microservices gespeichert werden und auf die Dauer nicht mehr übereinstimmen.
- Weil die Daten nicht zueinander in Beziehung gesetzt werden, können keine leistungsfähige, firmenweite Aussagen davon abgeleitet werden. Insbesondere im heutigen Zeitalter von AI und Machine Learning sind solche Informationen jedoch wichtiger denn je.
Microservices strukturiert nach fachlichen Funktionen mit einem gemeinsamen Persistenzlayer
Diese Architektur verwendet für alle Microservices einen gemeinsamen Persistenzlayer.
- Einige Features lassen sich nun autonom realisieren, weil die Daten zumindest für Lesezugriffe jedem Microservice zur Verfügung stehen könnten. Damit werden Abhängigkeiten zu anderen Teams minimiert und es wird weniger Abstimmungsbedarf benötigt.
- Die Daten sind miteinander in Beziehung gesetzt und eignen sich gut für mächtige, firmenweite Datenanalysen mit Machine learning und AI.
- Redundante Daten sollten mit dieser Architektur nicht mehr vorkommen.
Problematik
- Ein einziger gemeinsamer Persistenzlayer lässt sich in der Praxis meistens nicht realisieren.
- Eine simple Modularisierung in der man Tabellen zu Teams bzw. Microservices zuweist, führt nicht zum Ziel. Oft befinden sich in derselben Tabelle gleich mehrere Aspekte eines Elements und diese werden typischerweise von unterschiedlichen Microservices benötigt.
- Das Ownership von Tabellen kann nicht befriedigend gelöst werden, da mehrere Teams darauf zugreifen.