Mikroservices stellen ein eigenes Architekturkonzept dar, mit denen Anwendungen dezentral und entkoppelt entwickelt und betrieben werden können. Eine große Anzahl von Design Pattern macht es den Entwicklern dabei einfach, gute Architekturen zu erstellen.
Die Mikroservices Architektur wirkt sich jedoch nicht nur auf die Software aus, sondern bietet auch viel Potenzial um die Arbeit der Teams zu verbessern. Wie dies im speziellen aussehen kann, soll an dem sehr grundlegenden Pattern Database Per Service dargestellt werden.
Die folgende Abbildung zeigt eine traditionelle Backend Architektur. Sie besteht aus einem Business-Layer mit diversen Komponenten und einer Persistenz in Form einer Datenbank. Anfragen vom Frontend gehen bei den Komponenten ein und sorgen für Zugriffe auf die Persistenz.
Problematisch wird diese Architektur, wenn sie eine gewisse Größe erreicht hat und diverse Teams an der Software arbeiten. In der Abbildung sind die Bereiche rot markiert, in denen es zu Konflikten zwischen den Teams kommen kann. Die Komponenten können gemeinsamen Code besitzen oder auf zentrale Dienste in der Anwendung zugreifen. Wenn diese angepasst werden müssen, braucht es Absprachen zwischen den einzelnen Teams. Auch der Zugriff auf die Persistenz ist ein Problem, da auch hier alle Änderungen zwischen den Teams abgesprochen werden müssen. Auch Spezialisierungen der Teams auf spezielle Bereiche der Software hilft nur bedingt, da es mit dieser Spezialisierung zu Engpässen bei den Entwicklern durch Krankheit, Abwanderung oder Überlastung kommen kann.
Eine Lösung um diese Probleme abzuwenden, ist die Umwandlung der Anwendung in eine Mikroservices Architektur. Die folgende Abbildung zeigt die gleiche Anwendung in Form von Mikroservices.
Es fällt sofort ins Auge, dass es in dieser Abbildung sehr viel weniger Konfliktbereiche gibt. In dieser Architektur gibt es nur Bedarf für Absprachen zwischen Mikroservice 1, Mikroservice 2 und Mikroservice 3. Ansonsten können alle Mikroservices unabhängig voneinander weiterentwickelt werden. Bei der Persistenz gibt es durch das Pattern Database Per Service keinerlei Konflikte, da jeder Mikroservice seine eigene Persistenz besitzt. Als zusätzlichen Mehrwert zeigt diese Architektur, dass es Abhängigkeiten zwischen drei der vier Mikroservices gibt und Mikroservice 2 keine eigene Persistenz besitzt.
Abhängigkeiten statt lose Kopplung führte schon immer dazu, dass die Weiterentwicklung und Wartung von Software teuer und langsam wird. Viele Absprachen zwischen Teams und Abteilung sorgen für Bürokratie und große Vorabplanungen und ersticken damit Agilität und schnelle Marktanpassungen.
Ein weiterer interessanter Aspekt bei Database per Service ist die alleinige Hoheit des Service über die Datenbank. Nur über den Mikroservice wird in die Datenbank geschrieben und nur über den Mikroservice wird aus der Datenbank gelesen. Das klingt zunächst trivial, aber es bedeutet, dass kein Außenstehender weiß, ob die Datenbank tatsächlich genutzt wird. Wie im Beitrag Der Mikrokosmos und Makrokosmos der Microservices angesprochen, ähneln sich Mikroservices und Objekte. In diesem Fall haben wir eine Parallele zum Prinzip der Datenkapselung aus der Objektorientierten Programmierung.
Hier noch ein weiteres Mal die Mikroservices Architektur der Anwendung. Diesmal wurden die Mikroservices 1, 3 und 4 mit einem Caching Mechanismus ausgerüstet, der ohne weitere Änderungen an der Gesamtanwendung die Verarbeitung beschleunigt. Mit dem Mikroservice Pattern Domain Event kann dieser Ansatz sogar noch verbessert werden. Das ist aber Stoff für einen neuen Beitrag.