Wo ergibt das Zusammenspiel von Blockchain und Microservices Sinn?

Inhaltsverzeichnis

Blockchain und Microservices sind zwei der am häufigsten diskutierten Themen der jüngeren Vergangenheit. Nichtsdestoweniger scheint der Blockchain-Hype nun vorbei zu sein. Was bleibt, ist an vielen Stellen Ernüchterung darüber, dass die Blockchain-Technologie nicht der erhoffte Heilsbringer sein wird. Seit Aufkommen der Blockchain hat man erkannt, dass sich zwar viele Probleme mit den Konzepten der Blockchain lösen lassen, häufig jedoch nur unter großen Anstrengungen und verbunden mit hohen Kosten.

Alternativen sind kostengünstige und gut erprobte Konzepte und Techniken. Für diese Umsetzungen gibt es eine große Anzahl an Experten und Kataloge voller Best-Practices und prall gefüllte Werkzeugkästen. Problemstellungen, die man durch den Einsatz von Blockchains elegant lösen kann, scheinen stark limitiert zu sein und manchmal auch etwas konstruiert. War die Blockchain also nur ein Hype?

Bietet sich vielleicht eine Chance, die Blockchain-Techniken mit den Konzepten und Ideen der Microservices zu kombinieren? Kann die Blockhain helfen, die vielfältigen Herausforderungen zu lösen oder wenigstens zu mindern, die in verteilten Architekturen wie Microservices vielen Entwicklern und Architekten Kopfschmerzen bereiten?

Im Folgenden betrachten die Autoren nicht die dezentralisierte offene Welt der Blockchain, sondern sie bewegen sich im Umfeld von Hyperledger und teilprivaten Netzwerken, denn ihrer Meinung nach treffen diese am besten für die Anforderungen in wirtschaftlichen Kontexten zu, in denen sich auch Microservices sinnvoll umsetzen lassen. Nichtsdestoweniger wird es Randfälle geben, diese bestätigen dann die Regel.

Ein weiterer Punkt vorweg: Es ist den Autoren trotz intensiver Recherche nicht gelungen, den Use-Case so abzugrenzen, dass man ihn nicht auch mit anderen Techniken lösen könnte. Das scheint zum einen ein Symptom des abgeflachten Hypes und der stark verbreiteten Skepsis als auch an den besonderen Umständen zu liegen, bei denen sich Blockchain-Techniken einsetzen lassen.

Komplexe Objekte verwalten – aber bitte ohne Zustand

Wo lässt sich die Blockchain also sinnvoll im Rahmen von Microservices einsetzen? Die Antwort scheint zunächst einfach zu sein. Eine Blockchain ist nichts anderes als ein verteilter Zustandsautomat. Insbesondere durch die Digitalisierung und Industrie 4.0 und der damit aufkommenden Verwaltung von Entitäten im Internet of Things sind in hochskalierbaren verteilten Architekturen – Microservice-Anwendungen – häufig die Zustände komplexer Objekte zu verwalten. Dies reicht vom einfachen Management des Zustands eines Schließmechanismus bis hin zur komplexen Zustands- und Fehlerverwaltung von Turbinen in der Energiebranche oder Ladesäulen in der Elektromobilität.

Hier kann das Stateless-Pattern von Microservice-Anwendungen an seine Grenzen geraten, und man beginnt damit, die Zustände in herkömmlichen relationalen Datenbanken zu persistieren, um anschließend für die Zustandsübergänge komplexe Zustandsautomaten bei jeder Anfrage von vorne Aufzubauen. Im Kontext mit verteilten Anwendungen bedeutet dies plakativ einfach ausgedrückt: Man muss sich keine Gedanken mehr um das konsistente (verteilte) Verfügbarhalten von relationalen (oder anders gearteten) Datenbanken machen und könnte die Blockchain-Technologie einsetzen, um eben diese Zustände zu verwalten.

Darf's noch etwas mehr sein?

Gerne hätten die Autoren weitere Möglichkeiten beschrieben, bei denen ein Einsatz der Blockchain ein Mehrwert für Microservices bietet. Leider scheint es diese nicht in der Form zu geben, dass die Anwendungsfälle nicht wenigstens ein bisschen konstruiert wirken würden. Trotzdem soll das den Vorteil der Blockchain und den des verteilten Zustandsautomaten in Bezug auf heutige Bedürfnisse in (hoch)verteilten Anwendungen nicht mindern. Damit lässt sich ebenfalls eine Antwort auf die Frage finden, welchen Mehrwert die Blockchain-Technologie für Microservice-Anwendungen bietet.

Im Folgenden seien zwei Beispiele betrachtet, die aufzeigen sollen, was mit der plakativen Aussage gemeint ist, dass es kein Einsatzgebiet mehr gibt, an dem die Blockchain mehrwertstiftend für Microservice-Anwendungen fungiert.

Wer mit verteilten Systemen arbeitet und sie sogar betreiben muss, merkt schnell, dass das Logging in verteilten Systemen eine nicht zu unterschätzende Komplexität erreichen kann. Benötigt man die Logeinträge auch noch, um den Zustand eines verteilten Gesamtsystems abzuleiten, oder benutzt sie sogar als System of Record, um beispielsweise in einem Krankenhaus Änderungen an Krankenakten oder Behandlungsplänen zu auditieren, ergibt sich ein ernstzunehmendes Risiko. Die Logeinträge könnten manipuliert werden, um beispielsweise Behandlungsfehler zu verschleiern. Hier könnte die Blockchain ein spannendes Einsatzgebiet finden. Ihrer ursprünglichen Idee entsprechend könnte man die Logeinträge in den Blöcken verwalten und somit vor Manipulation schützen. Das setzt entsprechend starke Anforderungen an die Hashfunktion voraus, um den Proof of Work nicht zu einfach zu halten. Natürlich gibt es bereits Auditing-Systeme und man könnte im einfachsten Fall dieses System of Records in eine abgesicherte Datensenke ablegen, auf die eine starke Zugriffsbeschränkung und ein zusätzliches Auditing umgesetzt wurde.

Ein weiteres denkbares (und tatsächlich argumentativ aufgeführtes) Anwendungsgebiet ist die Systemkonfiguration für Microservices. Diese sollte grundsätzlich nicht zusammen mit dem Anwendungscode vorgehalten werden und bestenfalls externalisiert sein. Dafür gibt es verschiedene Ansätze. Auditing- und Verifikationssysteme können hierfür nur schwer umsetzbar sein. Das bietet einen weiteren Ansatzpunkt für Blockchains. Die Konfiguration ließe sich mit ihnen verwalten. Damit hat man eine Externalisierung der Konfiguration erreicht und kann gleichzeitig beliebig komplexe Verifikationsmechanismen in den Smart Contracts unterbringen. Das Auditing erfolgt nun über die Metainformationen in der Blockchain. Ebenfalls hätte man damit den weiteren Vorteil, dass ein unerwartetes oder unautorisiertes Ändern der Konfiguration nur schwer erfolgen kann. Benutzt man Git als Versionsverwaltungssystem für die Konfiguration und bindet das Git-Repository beispielsweise über einen Konfigurationsserver an, kann man dieselben Funktionen aber auch ohne die Blockchain erhalten.

Alles in den Mixer!

Nachdem nun geklärt wurde, welche fachlichen (und technischen) Anforderungen sich in Microservice-Anwendungen durch den Einsatz vonBlockchain lösen lassen und welche nicht, soll im Folgenden betrachtet werden, wie eine mögliche kombinierte Systemarchitektur für Microservices und Blockchains aussehen könnte.

Zunächst ist – theoretisch betrachtet – ein Microservice-System durch einen Message Broker in die Lage versetzt worden, asynchron zu kommunizieren (vgl. a in Abb. 1). Weiterhin wird an diesen Kommunikationskanal ein sogenannter Chain-Service (vgl. b in Abb. 1) angehängt, der für die Kommunikation zwischen Blockchain- und Microservice-System sorgt. Dieses System könnte zum Flaschenhals werden und sollte entsprechend skalierbar sein. Der Chain-Service verfügt weiterhin über zwei (Sub-)Komponenten, Blockchain-Reader und Blockchain-Writer (vgl. c in Abb. 1). Der Reader übernimmt das Lesen auf der Blockchain beziehungsweise delegiert diese Aufgabe an die Ledger und stellt somit Informationen aus der Blockchain für den Chain-Service zur Verfügung. Der Writer hingegen übernimmt die Schreibarbeit auf die Blockchain beziehungsweise die Delegation an die Ledger. Dahinter befindet sich ein durch die Ledger gekapseltes – wie auch immer geartetes – dezentralisiertes System an Peers, die die Verwaltung der Blockchain übernehmen (vgl. d in Abb. 1).

In der realen Welt

Um die Anforderungen, die Anwendungen in der realen Welt an die in Abbildung 1 skizzierte Architektur stellen, zu untersuchen, sei nun betrachtet, welche Informationsflüsse tatsächlich interessant werden können. Das Zusammenspiel von Blockchain und Microservices lässt sich in drei Spielarten unterteilen. Erstens ist aus Sicht der Applikation der aktuelle Status im Ledger interessant. Zweitens sollen Änderungen, die im Ledger passieren, sich in eine Applikation zurückspielen lassen und drittens sollen Transaktionen im Ledger ausgeführt werden.

Diese Interaktion kann mit vorgefertigten APIs erfolgen. Als Beispiel dient bei Hyperledger die Core-API. Dabei gilt es zu beachten, dass der Benutzerkontext, der in einer Applikation benutzt wird, nicht identisch mit der Security-Information in der Blockchain-Umgebung ist. Es findet eine Benutzerzuordnung statt, um allen Usern die Informationen zur Verfügung zu stellen. Weiterhin ist es nicht sinnvoll, alle Services mit beispielsweise der Hyperledger API auszustatten, da die Komplexität in den Services somit über die Grenzen eines Microservice ansteigen kann. Daher wird ein weiterer Layer zwischen die Anwendung und den Blockchain-Ledger gezogen (vgl. Abb. 2).

Werkzeugkasten

Aus der Umsetzung ergibt sich die Notwendigkeit, neben der Hyperledger-Umgebung eine Microservice-Plattform aufzubauen. Diese kann eine Orchestrierungssoftware wie Kubernetes sein oder ein beliebiger Cloud-Service. Ergänzt wird das durch einen Blockchain-Stack wie die Hyperledger Fabric. Die Entwicklung mit Microservices wird umrahmt durch Services wie eine Build-Pipeline (beispielsweise Jenkins oder Concourse), Testing-Tools sowie Analyse- und Logging-Frameworks. Dadurch ist zum Entwicklungsbeginn einer Anwendung eine hohe Anzahl an Software- und Framework-Elementen notwendig. Das wird die in verteilten Anwendungen übliche kognitive Komplexität weiter erhöhen. Daher ist es sinnvoll, bei so vielen Technikentscheidungen so viel wie möglich die Fähigkeiten des Entwicklerteams zu berücksichtigen und so oft wie nötig auf vorhandenes Know-how zurückzugreifen.

Da eine Blockchain-Umgebung meist nur im Zusammenspiel mit anderen Partnern (bzw. Teilnehmern) die vollen Möglichkeiten ausschöpft, erscheinen die Entwicklung und der Betrieb in einer Cloud-Umgebung sinnvoll, um die Zugriffs- und Kooperationshürden für weitere Teilnehmer möglichst gering zu halten. Ein weiterer Vorteil der Cloud-Entwicklung ist es, dass sich die Entwicklungsressourcen besser auf das gesteckte Ziel konzentrieren lassen, da, wann immer es möglich ist, auf von den Cloud-Anbietern verwaltete und bereitgestellte Dienste zurückgegriffen werden kann. Das reduziert den Aufwand des Entwicklungsteams, sich auf Entwicklung und Betrieb dieser Bausteine zu konzentrieren. Damit lässt sich eine stärkere Fokussierung auf die Anwendung erreichen. Es ist folglich auch weniger Aufwand in Infrastruktur- und Plattformkonfiguration zu investieren.

Was bleibt am Ende?

Die Blockchain bleibt eine spannende Technik. Wie die Autoren in der Einleitung herausgestellt haben und abschließend noch einmal betonen möchten, gibt es aber nicht den Anwendungsfall, bei der Microservice-Anwendungen zwingend von der Blockchain profitieren. Derzeit scheint es eher so, dass die Blockchain von den Konzepten hinter den Microservices hinsichtlich Lösungsansätzen für Skalierbarkeit und Erreichbarkeit deutlich mehr profitiert als anders herum. Das liegt neben den erwähnten beschränkten Anwendungsfällen für die Blockchain-Technik in Microservice-Applikationen, insbesondere an den Kosten, die der Einsatz einer Blockchain im Vergleich zu anderen Strategien nach sich zieht.

Nüchtern betrachtet ist die Blockchain nichts anderes, als ein verteilter Zustandsautomat. Daher kann man über die Blockchain zumindest immer dann nachdenken, wenn ein verteiltes System einen verteilten Zustandsautomaten umsetzen muss. Abschließend bleibt noch zu sagen, dass die Blockchain – wie im Übrigen alle anderen technologischen Innovationen – nicht das erhoffte Allheilmittel darstellt.

Dominik Galler
ist als Senior Consultant bei der esentri AG in der Entwicklung und Konzeption verteilter Anwendungen aktiv. Er hat immer Freude daran, neue Techniken auszuprobieren und für den Enterprise-Einsatz zu bewerten.

Matthias Fuchs
kümmert sich als Senior-Solution-Architekt bei der DevTops GmbH am Aufbau und Betrieb der Infrastruktur in Cloud- und On-Premises-Umgebungen. Seit mehr als 10 Jahren ist er im Umfeld von Architekturen im Datenbank- und Middleware-Umfeld tätig.

---