Microservices, eine Einführung – Teil 1 / 5

„The golden rule: can you make a change to a service and deploy it by itself without changing anything else?”

Sam Newman, Building Microservices.

Microservices sind spätestens seit 2014 bekannt geworden und haben inzwischen bei zahlreichen Software-Architekten Anklang gefunden. Dank den Erfolgen der Firmen Amazon oder Netflix durch skalierbare Microservice-Umgebungen, werden vielerorts Software-Monolithen zerschlagen. Aber was genau sind eigentlich Microservices? Dieser Fragestellung möchten wir in einer kleinen Serie an Blog-Einträgen nachgehen.

Bei einem Microservice handelt es sich in erster Linie um ein Architekturmuster der Informatik. Definitionsgemäß beschreibt ein Microservice eine unabhängig bereitgestellte Software-Komponente mit begrenztem Funktionsumfang. Ein Gesamtsystem setzt sich dabei aus mehreren fachlich unterschiedlichen Microservices zusammen. Diese sind in der Lage untereinander zu kommunizieren. Das Ziel von Microservices ist das Herunterbrechen von komplexen und starren Anwendungsstrukturen in kleine, austauschbare Dienste. Dies kann die Wartbarkeit der eingesetzten Komponenten erhöhen und die Fähigkeit zur Spezialisierung und eine horizontalen Skalierung der eingesetzten Dienste fördern. Microservices ermöglichen ein System in kleine und unabhängige Dienste aufzuteilen. Die Alternative sind klassische Software-Monolithen. In der Softwaretechnik beschreibt die monolithische Software-Architektur Systeme, welche als untrennbare Einheit konzipiert wurden oder über den Verlauf der Entwicklungsphase als eine solche Einheit zusammengewachsen sind. Kennzeichen einer monolithische Software ist die Bindung sämtlicher benötigter Komponenten innerhalb einer zentralen Anwendung.

Wenn ein System aus mehreren Komponenten besteht, wird von einem verteilten System gesprochen. Dabei präsentiert sich das verteilte System dem Benutzer gegenüber als ein zusammengehöriges Gesamtsystem. Die einzelnen Komponenten können dabei, über den Austausch von Interprozesskommunikation, ihre Aktionen untereinander koordinieren. Hierzu kann REST verwendet werden, welches innerhalb eines separaten Blog-Eintrages bereits vorgestellt wurde.

Anwendungsbeispiel

Als vereinfachtes Beispiel für die Verwendung einer Microservice-Architektur soll ein Onlineshop-System dienen. Auf diesem soll der Besucher über eine Webanwendung Artikel einsehen und bestellen können. Hierbei greift die Webanwendung dynamisch auf die einzelnen Funktionen der Microservices zu. Durch eine Entkopplung von fachlich nur wenig zusammenhängenden Komponenten, kann das Onlineshop-System in folgende Microservices gegliedert werden.

Artikel-Katalog
Der Katalog beinhaltet alle Artikel des Shop-Systems. Dabei besitzen die Artikel eine Beschreibung sowie einen Preis. Als Anforderung soll der Katalog durchsuchbar sein.

Warenkorb
In den Warenkorb werden Artikel aus dem Katalog für den späteren Erwerb zwischengespeichert. Der Warenkorb kann Artikel aus der aktuellen Sitzung des Benutzers sowie Artikel aus bereits abgeschlossenen Sitzungen zur internen Verarbeitung speichern.

Kaufabwicklung

Damit der Benutzer die hinterlegten Artikel im Warenkorb käuflich erwerben kann, muss der Bezahlprozess abgewickelt werden können. Hierzu nimmt der Dienst die Artikel aus dem Warenkorb des Benutzers entgegen, um den offenen Betrag zu kalkulieren und stellt Schnittstellen zu Online-Bezahldiensten, wie z. B. einer Bank, bereit um die Abwicklung des Kaufprozesses zu komplettieren.

Generierung der Rechnung

Ein weiterer Microservice übernimmt die Generierung einer Rechnung. Dabei stellt der Service dem Benutzer eine PDF-Datei über den getätigten Einkauf im Shop-System bereit.

Es ist ersichtlich, dass sich eine komplexe Anwendung aus mehreren kleinen Anwendungen zusammensetzen lässt, ohne dass dies für den Benutzer von erkennbarer und relevanter Bedeutung ist.
Im nächsten Teil der Blog-Beiträge wird auf zentrale Philosophie- und Design Prinzipien von Microservices eingegangen.

TR