Oftmals ist es ein Thema: Wie werden Microservices richtig geschnitten?!

Was ist ein Microservice?

Zu erst einmal sollte geschaut werden, was Microservices eigentlich sind. Ein Microservice im Kleinen ist z.B. eine Webanwendung, die einen einzigen Zweck hat. Man könnte beispielsweise (müsste man aber nicht) die Verarbeitung eines Kontaktformulars umsetzen. Das ist ein wirklich sehr einfaches Beispiel. Weiter findet man Microservices beim viel zitierten Amazon-Verkaufs-Portal. Da kann man natürlich eine ganze Reihe von Services identifizeren. Diese können unabhängig voneinander arbeiten und das ist ja gerade eine der Kerneigenschaften. Microservices werden über eine Oberfläche oder Schnittstelle angesprochen und verarbeiten Daten, legen diese ab, holen andere, usw. Wie dabei die Datenhaltung organisiert ist, spielt erstmal keine Rolle. Mehr dazu später.

Ein Microservice ist also ein Baustein innerhalb einer Softwarearchitektur. Bei der Beantwortung der Frage nach dem richtigen Schnitt eines Microservices muss man nun darauf schauen, welche fachlichen Aufgaben erledigt werden müssen.

Weitere Beschreibungen und eine allgemeingültige Definition findet man zur weiteren Lektüre bei Wikipedia 🙂

Eigenschaften von Microservices

Was dort nicht zu lesen ist, sind die Eigenschaften, die Microservices auszeichen. Sie begründen eine vernünftige Verwendung von Microservices. Dazu zählen:

  • Kommunikation
  • Persistenz
  • Technologiestack
  • Deployment
  • Ersetzbarkeit
  • Fehlertoleranz
  • Skalierbarkeit

 

Bedeutung für kleinere Projekte

Bei kleineren Projekten kann man ja davon ausgehen, dass weniger Bürokratie vorgegeben ist. Gemeint ist damit, dass es wenig Aufwand für die Anforderungserhebung gibt und dass weniger formal entwickelt wird, aber auch, dass die Entwickler mehr Selbstbestimmung über ihr Tun und damit mehr Verantwortung haben. Sofern die Architektur vorher nicht komplett festgelegt wird, hat der Software-Entwickler Möglichkeiten die Architektur mitzubestimmen und kann sich auch die Services zurechtschneiden.

Einfachstes Szenario

Mal ein ganz simples Beispiel: Es gibt eine Webseite, die keine Logik enthält, sondern nur Inhalte darstellt. Es gibt kein Login, keine Produkte zum Verkauf, ergo kein System, nur lose HTML-Seiten. Jetzt gibt es die Anforderung ein Kontaktformular zu integrieren. Was ist denkbar? php, Node.JS. Das liegt erstmal Nahe. Allerdings könnten wir uns auch vorstellen, dass man hier eine kleine Webanwendung auf Java-Basis entwickelt. Zugegebenermaßen wäre das nicht der erste Gedanke, aber für dieses Thema ist es dennoch erstmal passend.

Einfaches Haus auf einer Wiese

Nun wird entwickelt und am Ende sieht es so aus, dass per JavaScript ein Request an eine Webanwendung (meinetwegen über REST) übergeben wird. Innerhalb der Anwendung werden die Daten verarbeitet und per Mail versendet und es findet keine Speicherung der Daten statt. Genau diese Anwendung lässt sich, gerade weil sie so einfach ist, wiederverwenden. Kommt jetzt eine Speicherung dazu oder soll die Mail mit bestimmten Konfigurationen versendet werden, verkompliziert sich die kleine einfache Anwendung und es wird schwieriger sie wiederzuverwenden. Wenn wir sie so klein und fein lassen, lässt sie sich problemlos auch für andere Webseiten verwenden und sie stellt einen kleinen Microservice dar.

Szenario erweitern

Lassen wir das Projekt etwas größer werden, klassisch: Eine Benutzverwaltung. Jetzt kann man sich fragen, ob ein Microservice die Benutzerverwaltung darstellt. Na klar, das kann sie. Ganz häufig ist es so, dass Benutzer erstellt werden, die zu einer Gruppe zugeordnet sind und sich über die Kombination von Gruppen Rollen der Benutzer ergeben. Damit sind diese fachlichen Objekte nah beieinander. Diese Elemente werden in einer Datenbank persistiert und sollen jederzeit abgerufen werden können. Also wird hier beispielsweise ein Service gebaut, der über REST abgefragt werden kann. Es kommt bei ein und der selben Anfrage immer das gleiche Ergebnis zurück. Stellen wir uns vor, dass wir wieder ein Kontaktformular brauchen und es sollen Benutzer aus der Nutzerverwaltung angeboten werden. Brauchen wir dazu die komplette Datenhaltung der Benutzerverwaltung? Nein, brauchen wir nicht. Hier kann ein Service angefragt werden: gib-mir-alle-Benutzer-mit-Email-Adresse. Damit kann vom Webseitenbenutzer eine Auswahl getroffen werden. Der selektierte Benutzer kann nun samt Nachricht entweder per Mail verschickt werden oder, falls hier eine Speicherung nötig ist, diese in einer seperaten Datenbank abgelegt werden. Nachdem die beiden Microservices eine Weile in Verwendung waren, können sie einfach ausgetauscht werden. Bei dieser Erweiterung des Szenarios ist wirklich wenig zu beachten.

Häuser auf einfacher Wiese

Das waren zwei ganz einfache Beispiele. Kommen wir nun zu größeren Projekten.

Bedeutung für größere Projekte

Häufig finden wir bei größeren Projekten eine strengere Formalisierung. Verschiedene Rollen werden definiert und diese sollen nun gemeinsam eine Architektur erstellen. Meist gibt es Softwarearchitekten, die den technischen Projektleitern zur Seite stehen, wobei in technischen Konzepten wird viel Zeit damit verbracht wird, die derzeit bekannten Anforderungen zu dokumentieren und die Umsetzung zu planen. Die Anforderungen an größere Projekte werden viel feingranularer beschrieben, die Risiken erforscht und die Systemgrenzen aufgezeichnet.

Szenario größerer Projekte

Gehen wir nun von einem Szenario aus, bei dem es eine Webanwendung gibt, die wie ein Online-Shop funktioniert. Es ist kein vordefiniertes System, da es zu viele spezielle Anforderungen gibt und bei der Evaluation kein passendes System gefunden wurde. Bei einem Online-Shop benötigt man grundlegend folgende Komponenten: Stammdatenverwaltung (Kunden, Benutzer, Lieferanten), Warenkorb, Payment-Parts und natürlich die Produktverwaltung. Wenn man die Amazon-, Otto- oder Zalando-Webseiten anschaut, fallen noch einige weitere Komponenten auf. Grundlegend sieht es erstmal so aus, als könne man die Komponenten als Microservice betrachten und auch so entwickeln. Häufig passt das auch ganz gut, allerdings ist damit noch nicht geklärt, wie es mit den Daten aussieht. Wo werden welche Daten gespeichert? Müssen diese Daten überall persistent sein oder können Daten auch mal später zu einem Service gelangen?

Die frühen Microservices

In der ersten Phase der Microservice glaubte man an starke Unabhängigkeit. Jeder Microservice muss selbst alles tun, was er braucht. Er muss selbst die Daten halten und alle Operation durchführen. Die Microservices waren wie Wolkenkratzer die unverbunden nebeneinander stehen. Jeder Wolkenkratzer hat seinen eigenen Fahrstuhl, eigene Klimaanlagen, eigene Wasserversorgung, etc.

Skyline von HongKong

Mit dieser Strukturierung sah so aus, als hätte man damit eine schöne Anordnung erhalten, die man leicht überblicken und damit auch leicht Elemente austauschen könnte.

Weiterentwicklung von Microservices

In der Microservice-Architektur geht man allerdings davon aus, dass die Komponenten untereinander kommunizieren. So wie auf folgendem Bild sollte man es sich eher vorstellen in großen Projekten:

Spinnenweben am Strauch

Auf dem Bild sind sehr viele Abhängigkeiten zu sehen. In der realien Welt mag es nicht immer so sein, aber so verdeutlicht das Bild, dass die Komplexität der Ein-Komponenten-Software nicht verschwindet, sondern aufgeteilt wird. Der einzelne Baustein mag so einfach entwickelt sein wie im kleinen Projekt, aber im Ganzen und im Zusammenspiel der verschiedenen Komponenten wird eine Herausforderung deutlich. Einzelne Microservice können immer noch entfernt werden, ohne dass das ganze Netz zusammen bricht – lediglich ein paar Verbindungsstraßen würden fehlen. Deutlich wird auch, dass es einen Bauplan braucht. Wenn ein Microservice ausgetauscht werden soll, muss ganz klar sein, welche Schnittstellen vorhanden sind, welche Kommunikationswege  der auszutauschende Microservice berührt.

Bei größeren Projekten lässt sich nicht pauschalisieren, welcher Schnitt gut ist, denn es hängt von der Kommunikation, von den Schnittstellen oder der Wertigkeit im Gesamtzusammenhang ab.

Schnitte ändern sich

Im Laufe eines Projektes können sich aus den implementierten Entwicklungen Änderungen ergeben oder die Anforderungen sich ändern. Im Laufe eines Projektes sollte es normal sein, dass sich der Schnitt eines Microservice ändern kann. Wenn aus der Entwicklungsabteilung der Ruf laut wird, dass es eine Fehlentscheidung gab, hat es häufig mit der Architektur und damit mit dem Schnitt von Microservices zu tun. Weitere Gründe, wie die verwendete Technologien, sind natürlich auch möglich.

 

Fazit

Was lernen wir aus der Fragen nach dem richtigen Schnitt? Es kommt auf das Szenario an. Und zwar nicht auf das, welches am Projektanfang bekannt ist, sondern auf jenes am Projektende!