Seite 2: Streng geheim

Inhaltsverzeichnis

Vor knapp dreißig Jahren formulierte David Parnas das sogenannte Information Hiding Principle, bei dem durch die Kapselung von Daten die interne Implementierung vor den äußeren Benutzern versteckt ist. Microservices-Architekturen stellen es durch die Aufteilungen in einzelne Services sicher, da der Zugriff nur über wohl definierte Schnittstellen erfolgt. Dazu ist eine gewisse Organisation erforderlich, für die sich ein API-Gateway anbietet.

Als technischer Infrastrukturbestandteil bietet ein API-Gateway viele Funktionen wie das Registrieren von Diensten, die Schnittstellen anbieten, und das Management der Nutzer von Schnittstellen. Letztlich ist damit die gesamte interne Microservices-Struktur versteckt wie bei den Mustern Brücke oder Fabrik.

Viele am Markt verfügbare API-Gateways implementieren eine API Composition. Sie verbindet API-Aufrufe zu unterschiedlichen Microservices, sodass nach außen nur noch ein Aufruf nötig ist – ähnlich wie beim Kompositum-Pattern.

Das Muster Backend for Frontend (BFF) lässt sich alternativ zum API-Gateway-Muster verwenden. Ein Datenzugriffsmodul (Backend) kann Schnittstellen allgemein zur Verfügung stellen, die aber nicht auf die Bedürfnisse der jeweiligen Präsentationsschicht (Frontend) angepasst sind. In der Regel haben mobile Apps und komplexe Webanwendungen unterschiedliche Anforderungen an die Schnittstellengestaltung. Um ihren Anforderungen gerecht zu werden, können unterschiedliche Module die Datenzugriffs-Schnittstellen konsumieren und spezifisch für den jeweiligen Client zur Verfügung stellen.

Wiederholungen sind tabu

Die Vorgabe, Wiederholungen zu vermeiden, findet sich kaum in den klassischen Aufzählungen von Architekturprinzipien. Trotzdem ist es ein wichtiges Pattern, da Wiederholungen zu zusätzlichen Fehlern führen können. Für Microservices müssen Entwickler häufig Infrastrukturcode schreiben, den sie ebenso gut über ein Chassis generieren und dadurch Schreib- oder Kopierfehler vermeiden könnten. Im Bereich der objektorientierten Programmierung lässt sich Ähnliches mit Prototypen umsetzen.

Eine Anwendung dieses Prinzips ist auch die StranglerFig-Applikation. Der Begriff beschreibt eine Anwendung, die ähnlich wie eine Würgefeige Schritt für Schritt die Aufgaben der ursprünglichen abzulösenden Anwendung übernimmt. Entwickler müssen dabei das Original nicht vollständig neu schreiben, sondern können die Anwendung nach und nach in Teilen ersetzen und strukturieren. Diese Arbeitsweise entspricht dem Vorgehen eines Adapters oder Wrappers aus der Objektorientierung.

Auf einen Blick

Tabelle 1 zeigt die vorgestellten Architekturmuster und ihre Pendants in der objektorientierten Programmierung. Viele Patterns lassen sich auf die Microservices-Welt übertragen, da die Problemstellungen ähnlich sind und die Architekturprinzipien nach wie vor Gültigkeit haben. Analog zur Unterteilung der ursprünglichen Patterns in Erzeugungs-, Struktur- und Verhaltensmuster, hat Chris Richardson die Microservices-Muster in Gruppen einsortiert.

Architekturprinzip	Architekturmuster (Microservices)	Entwurfsmuster (OO-Programmierung)	Gruppe
Eindeutige Verantwortung	Microservice	Multiton	Anwendungsarchitektur
	Monolith	Singleton
Trennung von Verantwortlichkeiten	Dienst pro Funktion	Fliegengewicht	Muster Bereitstellung
	Dienst pro Container	Container
Lose Kopplung	Event Broker	Beobachter	Erhalt der Datenkonsistenz
	Transaktionaler Postausgang	Kommando
Geheimnisprinzip	API-Gateway	Brücke, Fabrik	Externe API
	API-Komposition	Kompositum
	Datenzugriff-für-Präsentation-Muster (Backend-for-Frontend, BFF)	Fassade
Wiederhole Dich nicht	Microservice Chassis	Prototyp	Querschnittsthemen
	Würge-Anwendung	Wrapper, Adapter