Microservices, der große Hype! Mit dem Einzug von Docker als sehr leichte Virtualisierung wurde es nochmal ein Stück leichter Projekte als derartige (Software-)Strukturen zu realisieren. Mittlerweile ist der Hype vorüber und Microservices sind eine von mehreren etablierten Architekturen. Wichtig: eine von vielen, ob sie auf das „Problem“ bzw. den Bedarf des „Stakeholders“ passt, steht auf einem anderen Blatt.

Wie ich lernen durfte, verwenden viele Menschen den Begriff des Microservice sehr unterschiedlich. Das sorgt immer wieder für Schwierigkeiten in der Kommunikation, denn wenn der Gesprächspartner ein anderes Bild im Kopf hat als man selbst, dann redet man sehr schnell aneinander vorbei und keiner ist glücklich bzw. fühlt sich missverstanden. Im Folgenden will ich ein wenig Licht ins Dunkel bringen bzw. eine aus meiner Warte wichtige Unterscheidung und Bezeichnungen die ich gerne verwende um Klarheit zu haben.

Aus meiner Erfahrung heraus wird der Begriff „Microservice“ in folgenden „Geschmacksrichtungen“ benutzt:

• technischer Mikroservice
• fachlicher Mikroservice

Bevor wir zu den Unterschieden kommen, es gibt selbstverständlich auch Gemeinsamkeiten.

Was Mikroservices eint

Mikro kommt von klein und im besten Falle meint kleiner auch übersichtlicher. Dies ist eine wichtige Gemeinsamkeit – egal ob fachlich oder technisch man beschreibt oder möchte eine Struktur haben die man noch gut überblicken kann. Gerade in der Software heißt das: Wenn man etwas ändert dann muss man nicht gleich Angst haben, dass einem alles auf die Füße fällt, weil die Abhängigkeiten und Querverbindungen so umfangreich sind dass man sich gar nicht erst ausmalen kann was alles den Bach runter geht wenn man eine Änderung durchführt.

Ganz häufig ebenfalls genannt werden hinsichtlich der Gemeinsamkeiten natürlich auch Technologien wie Docker, Podman, Kubernetes um einmal nur die aktuell wichtigsten zu nennen. Wichtig ist hierbei: Das sind typische Hilfsmittel um Microservices zu gestalten, einen absoluten kausalen Zusammenhang gibt es aber nicht zwingend. Man kann auch Mikroservices auf virtuellen Maschinen ausrollen und wenn man die Prozesstrennung auf einem Server genauer anschaut, dann ist das auch schon eine Art Mikroservice, auch wenn man es in der Regel nicht so nennt: Der Webserver hat im Speicherbereich des Datenbankservers nichts verloren, diese Form der Trennung gibt es aber schon sehr lange und sie ist aus gutem Grund sehr erfolgreich.

Wichtig und ebenfalls häufig genannt: Skalierbarkeit. Mikroservices baut man geschickter Weise so auf, dass diese ggf. mehrfach (auf unterschiedlichen Systemen) laufen können. Das Stichwort hier heißt horizontale Skalierung. Wenn der Ansturm ist, verteile ich die Last auf mehrere Schultern. Das wohl bekannteste Beispiel ist die Supermarkt-Kasse: Wenn die Schlange (Last) zu groß wird dann wird eine weitere Kasse aufgemacht, ist wieder weniger los, reduziere ich die Anzahl der offenen Kassen. Das ermöglicht es die Ressourcen effizient einzusetzen – im Supermarkt kann der Mitarbeiter die Zeit die er an der Kasse nicht gebraucht wird z.B. zum Auffüllen von Regalen nutzen.

Der technische Mikroservice

Spricht man unter Entwicklern oder auch DevOps, so ist man sehr nahe an der Technik. Dementsprechend wird der Mikroservice dort sehr häufig (aber eben nicht immer) als technischer Mikroservice betrachtet. Ich habe eine klare Aufgabenteilung: Der Datenbank-Prozess kümmert sich um die Datenhaltung, der Webserver um die Anfragen per HTTP(S) und dazwischen gibt es wahrscheinlich noch ein wenig Applikations-Code (wahlweise in PHP, Java, NodeJS oder was auch immer gerade passt).

Setzt man nun Docker ein, so sollte man pro Prozess einen Container bekommen, die Kommunikation erfolgt über Netzwerk-Sockets. Dabei ist noch nicht einmal gesagt, dass beide Prozesse auf der gleichen Maschine laufen, im Zweifel steht die Datenbank am anderen Ende der Welt (ob das dann sinnvoll ist, ist eine andere Sache). Kommt nun mehr Last dann kann ich in der Regel einfach mehr Container starten (auch wenn es da bei Datenbank natürlich noch das Thema ACID zu beachten gilt, häufig ist aber nicht die Datenbank der Flaschenhals sondern schon der Webserver kommt nicht hinterher). Brauche ich mehr Rechenleistung und die Aufgabe lässt sich parallelisieren kann ich auch hier einfach weitere Container hochfahren und jeder schnappt sich einen Teil der Arbeit (siehe Supermarktkasse). Sinnvoller Weise sollten die Aufgaben dann nicht auf der gleichen Hardware laufen, wenn die schon am Limit ist, dann macht ein zusätzlicher Container die Sache an der Stelle sogar eher schlimmer denn besser.

Merke „technischer Mikroservice“: Wir reden tatsächlich über einzelne Container-Instanzen.

Der fachliche Mikroservice

Meist eine Stufe höher in der Abstraktion findet sich der fachliche Mikroservice. Wie üblich wenn man die Abstraktionspyramide nach oben geht, werden die Element mit denen man es zu tun hat etwas gröber.

Das ist genau der Punkt an dem viele Product-Owner, Abteilungsleiter oder Manager vom Mikro-Service reden. Gemeint ist dabei aber nicht zwingend die Verteilung auf einzelne Prozesse (das wäre zu fein granular), stattdessen geht es um einzelne „Funktionen“ in einem Unternehme. Im E-Commerce hat sich bei entsprechend großen Unternehmen eine Aufteilung in verschiedene Fachgebiete durchgesetzt, z.B. Suche, Warenkorb, Checkout, Payment, Logistics. Ganz wichtig dabei ist: die einzelnen Aufgabenbereiche agieren unabhängig voneinander über definierte Schnittstellen (das können Rest-APIs sein, aber jeder andere Form der Schnittstelle geht fast genauso gut). Ob innerhalb eines Aufgabenbereichs dann noch eine weitere Unterteilung stattfindet und ob diese dann ggf. technische Mikroservices oder doch eher einen monolithischen Ansatz verfolgen ist für den fachlichen Mikroservice unerheblich. Wichtig ist: Die Aufgaben sind für ein Team überschaubar, es geht also nicht darum von der Beschaffung bis zur Auslieferung von Ware oder Leistungen an den Kunden alles zu beherrschen sondern nur einen (An)-Teil. Den sollte man dann aber eben richtig gut machen.

Fazit

Die Welt ist voller Homonyme und der Terminus „Mikroservice“ macht da keine Ausnahme. Es lohnt sich daher immer, einmal genau nachzufragen was denn nun der Gesprächspartner meint. Dabei schließen sich die beiden Konzepte nicht einmal gegenseitig aus – ganz im Gegenteil: technische Mikroservices sind ganz häufig die Grundlage für eine Mikroservice-Architektur auf der organisatorischen Ebene.