Technische Dinge für Nicht-Technische Leute (Teil 2)

Nachdem ich im ersten Teil meiner Blog-Serie „Technische Dinge für nichttechnische Leute“ verschiedene Datenformate näher beleuchtet und deren Unterschiede erklärt habe, möchte ich euch nun das Thema „Microservices“ genauer vorstellen.

Services im Allgemeinen

Wenn ihr verstehen möchtet, was Microservices sind, müsst ihr zunächst einmal wissen, was ein Service ist. In der IT-Branche wir der Begriff „Service“ häufig und in den verschiedensten Zusammenhängen genutzt. Wie ihr euch sicher denken könnt, ist mit dem Begriff „Service“ erstmal nichts anderes gemeint als ein Dienst. Dieser kann unterschiedliche Funktionen haben. Beispielsweise um einen weiteren technischen Service oder auch den User, der etwa in seinem Browser oder E-Mail-Programm arbeitet, zu unterstützen.

Einfach gesagt: Ein Service dient einem Client (einem E-Mail-Programm oder Browser beispielsweise), um Daten zu bekommen oder zu liefern.

Monolithen

Betrachten wir einen Service nun einmal etwas genauer. Es fällt auf, dass der Service in viele Komponenten aufgeteilt ist. Diese Komponenten können ganz unterschiedlich geschnitten werden - in den 80er und 90er Jahren wurde beispielsweise die sogenannte N-Schichten-Architektur eingeführt. Dieses Strukturierungsprinzip versucht, Daten, Funktionen und Präsentation zu trennen. Wie ihr auf der folgenden Grafik seht, entstehen auf diese Weise verschiedene Schichten (englisch: tiers). Darunter fallen die Präsentations-, Business-Logik- und Daten-Schichten.

Eine solche N-Schichten-Architektur tendiert dazu ein Monolith zu werden – damit meine ich ein Modell, indem keine großartigen Strukturierungen mehr vorgenommen werden können. Der Grund dafür ist, dass die strenge Trennung zwischen Business-Logik und Benutzer-Interface nicht mehr gehalten werden kann (oder manchmal auch gar keinen Sinn mehr macht). Ihr könnt euch das so vorstellen: Werden Benutzereingaben jedes Mal nur auf dem Server geprüft, ist das sehr benutzerunfreundlich, da der User warten muss, bis er seine gewünschte Aktion ausführen kann. Auf der anderen Seite kann es manchmal schlichtweg einfacher, kosteneffizienter und schneller sein, bestimmte Business-Logiken in die Datenschicht mit Triggern und Stored Procedures zu packen.

Solche Monolithen haben allerdings jede Menge Nachteile. Der Größte besteht darin, dass die Installation sehr komplex und zeitaufwändig ist. Möchtet ihr beispielsweise lediglich eine Kleinigkeit ändern – etwa ein zusätzliches Feld für eine Straße bei einer Adressabfrage – müsst ihr die Präsentationsschicht, die Business-Logik und die Datenschicht ändern. Jede dieser Schichten muss separat installiert werden. Oft verlangt eine solche Installation auch eine Downtime – also eine gewisse Zeit, in der euer System nicht zur Verfügung steht. Da Downtimes in modernen Web-Anwendungen allerdings nicht mehr akzeptiert werden und nur selten stattfinden können – sagen wir viermal im Jahr – können Änderungen auch dementsprechend nur selten dem Benutzer zur Verfügung gestellt werden. Die zunehmende Digitalisierung macht es allerdings notwendig, Änderungen und Aktualisierungen in kürzester Zeit zur Verfügung zu stellen.

Eine Lösung – aber nicht die Antwort auf alles: Microservices

Kommen wir nach dieser kurzen Einführung zum eigentlichen Thema zurück: Den Microservices. Über Microservices wurde das erste Mal durch eine Gruppe von Softwareingenieuren nachgedacht, die genau mit den oben beschriebenen Problemen von monolithischen Anwendungen konfrontiert wurden. Sie wollten einen Architekturstil schaffen, der besser für moderne Web-Applikationen geeignet ist, da diese ständig verfügbar, hochperformant und stabil sein müssen. Zudem sollten diese Anwendungen „robust“ gegenüber Änderungen und Aktualisierungen sein, so dass eine kleine Änderung auch während der Installation nur eine kleine Änderung bleibt.

Um diese Anforderungen erfüllen zu können, stellen die folgenden Punkte unverzichtbare Grundvoraussetzungen dar. Der Service:

• darf keine Downtime beinhalten und der Betrieb muss vollautomatisiert erfolgen. Microservices können nämlich nicht mehr manuell installiert werden, da dies schlicht zu lange dauern würde.
• darf nur aus nur einer Business-Funktion, die er erfüllt, stammen. Ein Microservice braucht nämlich keine weiteren Komponenten – beispielsweise eine Datenbank – um seine Funktion zu erfüllen.
• muss belastbar (Resilienz) sein. Das heißt, wenn ein anderer Service, der mit diesem Service kommuniziert, nicht mehr arbeitet, muss der erste Service weiterarbeiten.
• muss hochskalierbar sein, denn wird eine zusätzliche Instanz des Service zu den augenblicklich schon existierenden Knoten hinzufügt, wird das Gesamtsystem performanter.

Zu guter Letzt müssen feingranulare Dienste, bei denen jeder Service genau eine Business-Funktion erfüllt – etwa die eines Einkaufswagens – vorhanden sein.

Anhand eines konkreten Beispiels – nämlich an einer Einkaufswagenanwendung – möchte ich euch zeigen, wie das Ganze funktionieren kann. Zerlegen wir die Einkaufsanwendung in Business-Funktionen, bekommen wir wahrscheinlich das folgende Bild.

Wie ihr seht, häuft die Einkaufsanwendung jede Menge Business-Funktionen an. Sie hat sogar Funktionen, die sich mehrere andere Funktionen teilen – etwa das „Access Management“ oder „Monitoring and Logging“.

Wichtig ist, dass die Business-Funktionen, die eine Unabhängigkeit aus der Business-Fragestellungen heraus benötigen, identifiziert werden. Gemeint sind damit zum Beispiel unterschiedliche Skalierbarkeits- oder Verfügbarkeitsanforderungen. Ein Beispiel: Die Find-Product-Funktion muss beispielsweise 24/365 verfügbar sein. Die Catalog-Management- Funktion muss hingegen nur während der normalen Bürozeiten verfügbar sein, da der Kataloginhalt dem Einkaufssystem durch die Catalog-Provider-Funktion zur Verfügung gestellt wird.

Die Vorteile von Microservices liegen auf der Hand: Da sie klein sind, erlauben sie schnelle Veränderungen im Code und auf der Produktion. Diese Änderungen in einer gesamten Organisation zu kommunizieren, braucht allerdings zu viel Zeit. Daher muss das Team, das die Änderungen entwickelt, diese auch installieren und betreiben. Wie ihr euch denken könnt, bedeutet das ein gewisses Umdenken in der Unternehmenskultur.

Fazit

Anwendungen mit geringer Komplexität können als Monolith entwickelt und installiert werden. Bestehen allerdings hohe Anforderungen hinsichtlich Skalierbarkeit und Stabilität, stellen Microservices eine gut strukturierte, hochverfügbare und stabile Anwendung dar. Allerdings verlangen sie einen hohen Grad an Automation und ein gewisses Maß an Veränderung in der Unternehmenskultur.

Zwar habe ich nur an der Oberfläche gekratzt, aber ich hoffe dennoch, dass ich euch mit meinem Beitrag einfach und verständlich erklären konnte, was ein Microservice ist und wann er benötigt wird.

In meinem nächsten Blog-Beitrag werde ich mich übrigens mit dem Thema Online-Deployment befassen. Es bleibt also interessant.

Ihr möchtet mehr zu spannenden Themen rund um Software, Entwicklung oder auch aus Projekten erfahren? Dann werft doch einen Blick in unsere anderen Blog-Beiträge.