Why Reactive: Reaktive Architekturen und ihre Geschichte

Inhaltsverzeichnis

Was haben Rammstein-Tickets, das Baukindergeld und die Jubiläumstrikots des SV Werder Bremen gemeinsam? Alle drei waren so begehrt, dass die jeweiligen Webseiten zum Buchen der Tickets, Beantragen der Förderungen und Ordern von Leibchen innerhalb kürzester Zeit unter dem Besucheransturm zusammengebrochen sind.

Neben der Wut und Enttäuschung der Kunden und Bürger und dem damit verbundenen Reputationsverlust für die Anbieter sind derartige – durch zu hohen Traffic verursachte – Ausfälle meist auch mit massiven finanziellen Einbußen verbunden. In manchen Geschäftsmodellen und Einsatzszenarien wären sie geradezu fatal: Streamingdienste wie Netflix und Spotify, IoT-Netze in Smart Cities und autonome Fahrzeuge sind essentiell darauf angewiesen, dass die ihnen zugrundeliegenden Systeme unter allen Umständen unabhängig vom Datenaufkommen und der aufzubringenden Performance arbeitsfähig bleiben.

Post-Mortem: Callback-Problem bei Netflix

• Vor kurzem hatte Netflix ein Post-Mortem veröffentlicht zu einem Callback-Problem in der Softwarearchitektur: Im Allgemeinen kam der Callback nach 15 Millisekunden, aber eben nicht immer. Gelegentlich brauchte er deutlich länger, was zu Problemen beim Abspielen führte.
• Das Scheduler-Framework von Android hatte einen Callback von 15 Millisekunden beantragt – das besagt jedoch lediglich, dass der Callback mindestens 15 Millisekunden brauchen darf (nicht höchstens, sondern mindestens, wie der Sicherheitsexperte Felix von Leitner in einem Blogeintrag erläutert). Der Bug wäre durch ein anderes Softwaredesign möglicherweise vermeidbar gewesen.

Das Reactive Manifesto entstand 2013 aus der Zusammenarbeit der Softwareentwickler Jonas Bonér, Dave Farley, Roland Kuhn und Martin Thompson. Seither haben rund 27.000 Entwickler das Manifest unterschrieben, und fast alle Publikationen zum Thema Reactive beziehen sich darauf. Es definiert Werte, nichtfunktionale Anforderungen und Prinzipien, die für eine reaktive Architektur stehen (s. Abb. 1).

Reaktive Architekturen dringen immer tiefer in Softwareanwendungen ein, die Ziele und Absichten dieser Architekturform beschreibt dieses Grundsatzpapier. Allerdings scheint es auf den ersten Blick keine neuen Erkenntnisse zu liefern. Ein Blick in die historische Entwicklung der Architekturstile lohnt sich, um das Konzept besser zu verstehen.

Der wichtigste Wert laut Manifest ist Responsivität, das schnelle und zuverlässige Antwortverhalten reaktiver Anwendungen. Elastizität und Resilienz (beides nichtfunktionale Anforderungen) sollen zu diesem Verhalten führen: Dabei steht Elastizität für eine dynamische Skalierung abhängig vom Lastverhalten, und Resilienz dafür, Ausfälle zu erkennen und selbstständig zu beheben.

Das Lastverhalten kann unterschiedlich ausgeprägt sein. Mal sind es die Zugriffe von Benutzern aus dem Internet, mal das Senden von MQTT-Nachrichten eines IoT-Device. Beispielsweise lässt sich die Elastizität in einer Microservices-Architektur dadurch erreichen, dass Microservice-Instanzen bei steigender Last hinzutreten und bei sinkender Last wieder herausgehen. Resilienz lässt sich in einer Microservices-Architektur erreichen, indem man mehrere Microservice-Instanzen redundant bereitstellt, sodass im Fehlerfall eine andere Instanz die Aufgaben übernehmen kann. Das System erkennt den Fehlerfall automatisch und startet die Microservice-Instanz neu, sodass sie die Aufgaben wieder übernehmen kann. Asynchrone Kommunikation via Messaging soll diesen Anforderungen gerecht werden.

Softwarearchitektur im historischen Rückblick

Für Softwarearchitekten ist das nicht neu, denn sie achten von Haus aus darauf, dass die von ihnen gebauten Anwendungen schnell und zuverlässig antworten. Ihnen ist in der Regel schon seit Längerem bewusst, dass das nur möglich ist, wenn die Anwendungen gut skalieren und robust gebaut sind. Die meisten von ihnen versuchen auch, asynchrone Kommunikation mittels Benachrichtigungen einzusetzen. Allgemein gesprochen sind das die Eckpunkte, die verteilte Systeme ausmachen und die Softwarearchitekten nach jahrelanger Praxiserfahrung kennen. Was aber steckt hinter dem Reactive Manifesto, und warum ist es dann wichtig? Um diese Frage beantworten zu können, ist ein Blick in die geschichtliche Entwicklung verteilter Systeme notwendig.

Abbildung 2 zeigt drei epochale Softwarearchitekturstile: Client-Server-, Cloud-native- sowie Streaming-Architekturen. Jeder dieser Architekturstile musste die Anforderungen seiner jeweiligen Epoche erfüllen und konnte dafür die zu dieser Zeit verfügbaren Potenziale einsetzen, die ihnen die IT bereitstellte. Die Vorgaben des Reactive Manifesto haben sie dabei mehr oder weniger erfüllt.

Erste Epoche: Client-Server-Architektur

In den 1980er-Jahren hielten IT-gestützte Informationssysteme in die Unternehmen Einzug, mit denen sich Arbeitsabläufe optimieren ließen. Über die Jahre hinweg entstanden unterschiedliche Arten von Informationssystemen wie Enterprise Ressource Planning (ERP). Die Grundlage für Informationssysteme ist eine Client-Server-Architektur wie in Abbildung 3 gezeigt. In den 1990er-Jahren kamen mit der Erfindung von HTTP und HTML sogenannte webbasierte Client-Server-Systeme hinzu (und sind bis heute geblieben). Ende der 1990er-Jahre hielt dann Java Einzug in die Unternehmen. So ließen sich auf Basis der Java 2 Platform Enterprise Edition (J2EE) webbasierte Informationssysteme mit Servlet und JSPs bauen, die noch heute in den Unternehmen anzutreffen und produktiv im Einsatz sind.

Webbasierte Client-Server-Systeme haben das primäre Ziel, zentrale Informationen unternehmensweit und meist nur für die Mitarbeiter bereitzustellen. Das ist eine essenzielle Eigenschaft verteilter betrieblicher Informationssysteme. Allerdings spielen die Forderungen nach Elastizität und Resilienz aus dem Reactive Manifesto hier nur eine untergeordnete Rolle.

IT-Ressourcen auf der Serverebene

Die unternommenen Anstrengungen, um eine gute Antwortbereitschaft sicherzustellen, konzentrieren sich im Wesentlichen auf die Serverebene. In der Regel verteilt sich die Last auf einen oder mehrere Server. Die Anzahl der Server ist allerdings statisch und ändert sich nicht dynamisch in Abhängigkeit von der Lastsituation. Auch das Verhalten im Fehlerfall ist statisch. Fallen einer oder mehrere Server aus, ist das System nur teilweise oder gar nicht mehr verfügbar. Die Server werden meist nicht automatisch überwacht und im Fehlerfall nicht neu gestartet. Das erfüllt die Anforderungen aus dem Reactive Manifesto nur bedingt.

Für betriebliche Informationssysteme ist das aber auch kein Problem. Denn die Unternehmen haben es mit einer bekannten und relativ stabilen Anzahl von Mitarbeitern zu tun, sodass sich die Anzahl der Server darauf auslegen lässt. Sofern das System einmal für ein paar Stunden ausfällt oder die Mitarbeiter bei größeren Datenmengen etwas länger auf ein Ergebnis warten müssen, ist das immer noch besser, als die Tätigkeit ohne IT-Unterstützung durchzuführen.

Zweite Epoche: Öffnung des Internets für private Nutzer mit dynamischen Anwendungen

Im Jahr 1990 beschloss die National Science Foundation (NSF) der USA, das Internet für private Zwecke freizugeben. Damit war der Grundstein der vierten industriellen Revolution, der sogenannten digitalen Revolution, gelegt. Der Durchbruch des World Wide Web, das zunächst nur Nerds und Universitäten nutzten, erfolgte 2003 mit dem Web 2.0. Es ermöglichte Nutzern, eigene Inhalte als Text-, Audio- oder Videodateien ins Netz zu stellen und untereinander auszutauschen. Die Web-2.0-Anwendungen, die zunächst dem heimischen Desktop vorbehalten waren, griffen ab 2010 rasch auf mobile Endgeräte über. Damit war die Bühne frei für das Zeitalter des mobilen Internets. 2019 gab es bereits über drei Milliarden Internetnutzer weltweit.

Diese Entwicklung hatte erhebliche Auswirkungen auf Wirtschaftsunternehmen, die seit Anfang der 2010er-Jahre mit der digitalen Transformation konfrontiert sind. Die digitale Gesellschaft stellt neue Anforderungen an die Anwendungen ihrer Zeit: Sie müssen rund um die Uhr zur Verfügung stehen, schnell antworten und sollen ihre Anwender auch noch begeistern. Dafür sind klassische Client-Server-Architekturen nicht immer geeignet. 2011 führte Geoffrey Moore den Begriff der Systems of Engagement (SoE) ein [1]. Diese Systemklasse soll die Anforderungen der Digitalisierung beschreiben und abdecken. Zwei grundlegende Probleme galt es zunächst zu lösen.

• Dynamische Bereitstellung von Ressourcen in der Cloud: Die erste Herausforderung war, eine gute Antwortbereitschaft der Anwendung sicherzustellen, ohne die Anzahl und das Verhalten der Nutzer im Internet genau zu kennen. Das erforderte eine dynamische und kosteneffiziente Bereitstellung der IT-Ressourcen in Form von Servern, Netzwerk und Speicher. Die Cloud schafft hier Abhilfe. Bereits 2006 konnte Amazon mit den Amazon Web Services (AWS) den Unternehmen eine Cloud bereitstellen, die per Infrastructure as a Service (IaaS) funktionierte.
• Monolithen aufbrechen mit Microservices: Das zweite Problem bestand darin, dass die bisher verwendeten monolithischen Anwendungen eine schlechte Elastizität und Resilienz zeigten. Dieses Problem löste die Microservices-Architektur. Das Konzept der Architektur ist auf Martin Fowler zurückzuführen, der sie erstmals in einem seiner Workshops vorstellte und diskutierte.

Die Microservices-Architektur ist elastisch, weil sich Microservices mit steigender und fallender Last neu starten und auch wieder anhalten lassen. Sie ist zudem resilient, weil der Ausfall eines Microservices nicht zum Ausfall der gesamten Anwendung führt. Container-Werkzeuge wie Docker und Werkzeuge für das Scheduling und die Orchestrierung, etwa Kubernetes, übernehmen meist die Verteilung der Microservices auf die Cloud-Ressourcen.

2014 prägten Netflix und Amazon dafür den Begriff „Cloud-native Architecture“, den Abbildung 4 detaillierter darstellt. Eine Cloud-native Architektur erfüllt die Anforderungen aus dem Manifesto schon sehr gut, wesentlich besser jedenfalls als die klassische Client-Server-Architektur, wie sie in der ersten Epoche anzutreffen war.

Der Fokus der Cloud-nativen Architektur liegt auf der Server- und auf der Anwendungsebene zugleich. Auf der Serverebene stellt die Cloud unbegrenzt hochverfügbare Server bereit, die sich dynamisch skalieren lassen. Auf der Anwendungsebene lassen sich Microservices mehrfach instanziieren und über Container sowie Scheduling und Orchestrierung optimal auf die Server verteilen. Das nutzt das Potenzial auf diesen Architekturebenen gut. Die Möglichkeiten in anderen Architekturbereichen, etwa durch eine effiziente Netzwerkkommunikation, bleiben hingegen teilweise oder vollständig ungenutzt.

Allerdings scheint die Cloud-native Architektur für Unternehmen das zu leisten, was sie sich davon versprechen: Die Unternehmen bringen ihre neuen Produkte und Services per APIs und mobilen Apps ins Internet.

Dritte Epoche: Das Internet der Dinge

Das Internet of Things (IoT) dringt zunehmend tiefer in das tägliche Leben ein. Die Zukunftsvisionen von Mark Weiser – die er 1991 in seinem legendär gewordenen Artikel „The Computer for the 21st Century“ [2] beschrieben hat – scheinen Wirklichkeit zu werden. Für das Jahr 2020 nennen die Prognosen über 20 Milliarden vernetzter Geräte. Damit ergeben sich über das IoT-Protokoll Sigfox Datenströme von 2,24 Milliarden Bytes pro Sekunde. Da in den nächsten Jahren ein rasantes Wachstum im IoT-Markt bevorsteht, ist bei den Datenströmen weiterhin mit einem enormen Wachstum zu rechnen.

Netflix oder Spotify sind zwei Beispiele für Streaming-Unternehmen, die sich erfolgreich in diesem Markt etabliert haben. 2019 beanspruchte Video-Streaming weltweit 60 Prozent des gesamten Internet-Traffics. Für das Video-Streaming allein rechnen Prognosen ein Umsatzvolumen von 22 Millionen Euro im Jahr 2020 vor. Die Datenströme nehmen weiterhin rasant zu.

Auch soziale Netzwerke tragen wesentlich zum täglichen Datenstrom im Internet bei. Stichworte sind hier Big Data oder Predictive Data Analytics. Zwei bekannte Datentreiber im Umfeld sozialer Netze sind Instant-Messaging-Dienste und das Microblogging. Allein über WhatsApp haben Anwender 2019 über 65 Milliarden Nachrichten pro Tag verschickt. 2006 entstand mit Twitter der erste Microblogging-Dienst, über den Nutzer heute täglich mehr als 500 Millionen Tweets weltweit versenden.

Große Datenblöcke in Einheiten zerlegen

Für die beschriebene Art von Anwendungen sind Streaming-Architekturen, wie Abbildung 5 sie darstellt, zwingend notwendig. Sie legen den Fokus darauf, das Potenzial auf Daten-, Thread- und Netzwerkebene effizienter zu nutzen, um die enormen Datenströme kontinuierlich und ohne Unterbrechung zu verarbeiten. Das ist auch notwendig, denn IoT-Sensoren müssen ihre Daten zeitnah loswerden und können sie nicht zwischenspeichern. Kunden erwarten einen fortlaufenden Video- und Audio-Stream für ein gelungenes Filmerlebnis, Twitter-Nachrichten leben von ihrer Aktualität und lassen sich nicht in eine Warteschleife auslagern.

Um eine effiziente Verarbeitung von Daten zu ermöglichen, gilt es, große Datenblöcke in kleine Einheiten zu zerlegen und in eine eindeutige Reihenfolge zu bringen. Aus den Datenblöcken entstehen geordnete Datenströme (engl. data streams). Für deren Verarbeitung ist in aller Regel ein komplexes Data Stream Processing notwendig: Das bedeutet, dass die Daten zu filtern und zu aggregieren sind. Bei der sukzessiven Ausführung dieser Operationen besteht die Gefahr einer Verstopfung, wonach sich keine weiteren Daten mehr verarbeiten lassen. Ohne eine Parallelisierung der Operationen ist eine kontinuierliche, nicht blockierende Verarbeitung der Datenströme unmöglich.

Parallelisierung mit Threads

Das Problem der Parallelisierung lässt sich durch Threads lösen. Software-Plattformen wie Java SE parallelisieren Operationen über sogenannte User Threads. Streng genommen werden die User Threads nicht ganz parallel ausgeführt, denn sie konkurrieren alle um die gleichen Ressourcen, etwa um Speicherplatz oder um die Zeit eines Prozessors. Das hat sich mit der Einführung von Multicore-Prozessoren entschärft, die heute beispielsweise mit 16 Kernen und Hyperthreading-Technologie bis zu 32 Kernel-Threads auf einem Prozessor parallel ausführen. Dabei übernehmen Multithreading-Betriebssysteme die Abbildung von User Threads auf Kernel-Threads.

Seit 2014 stellt Java SE 8 mit den Futures eine User-Thread-Abstraktion zur Verfügung, mit der eine Anwendung Operationen asynchron ausführen kann, etwa eine Netzwerkoperation über HTTP. Allerdings haben Futures einen Nachteil: Die Anwendung muss über Polling das Ende der Operation prüfen und erhält das Ergebnis anschließend über einen einzigen Aufruf, also nicht in Stücken. Das CompleteableFuture, eine Erweiterung des Futures, verbessert das Verhalten nicht wesentlich. Es ermöglicht lediglich, mehrere Futures miteinander zu kombinieren, um eine sinnvolle Synchronisierung zusammenhängender Operationen zu ermöglichen. Und genau hier kommen die Reactive Extensions ins Spiel.

Eric Meyer, früher Professor an der Universität Utrecht und heute Softwarearchitekt bei Microsoft, ist Erfinder der Reactive Extensions und publizierte sie 2012 als Open-Source-Software. Im Zentrum der Reactive Extensions steht das Observer Pattern. Dabei repräsentiert das Observable eine Datenquelle, aus der Datenströme fließen, beispielsweise einen File-, Socket- oder Twitter-Datenstrom. Alle involvierten Observer der Anwendung bekommen die Daten zugeleitet. Damit entfällt das umständliche Polling, denn die Observer erhalten die Daten aktiv per Push.

Pivotal, Netflix und Red Hat haben Meyers Idee 2014 aufgegriffen und in eine Spezifikation mit dem Namen Reactive Streams [12] gegossen. Die Spezifikation besteht aus einer API und aus Regeln, wie die Schnittstelle zu verwenden ist. In den letzten Jahren ist eine Vielzahl von Frameworks aus dem Boden geschossen, die diese API implementieren. Dazu gehören RxJava, Project Reactor aus dem Spring-Ökosystem, Akka oder Vert.x. Diese Frameworks bringen neben der Implementierung der Spezifikation noch zahlreiche Operationen mit, die auf Datenströmen parallel ausführbar sind.

Nicht blockierendes Netzwerk als neuer Ansatz

Auch auf der Netzwerkebene gibt es noch Optimierungspotenzial. Schließlich ist das auf „Request and Response“ ausgerichtete HTTP-Protokoll nicht besonders gut für eine asynchrone Übertragung kontinuierlicher Datenströme zwischen Client und Server geeignet. Vor allem dann nicht, wenn der Server dem Client asynchron Daten senden möchte. Dieses Problem löst das Anfang der 2010er-Jahre eingeführte WebSockets-Protokoll. Im Gegensatz zum HTTP-Protokoll lassen sich Daten asynchron und bidirektional zwischen Client und Server übertragen. Damit wird der Client nach einer Anfrage nicht blockiert, sondern erhält das Ergebnis vom Server asynchron, sobald es bereitsteht.

Allerdings gibt es noch mehr Luft nach oben, etwa beim Umgang des Servers mit den Threads. Der Server benötigt für jeden Client genau einen Thread. Dieser erhält erst dann die Freigabe für einen anderen Client, wenn die Verbindung zwischen Server und Client geschlossen ist. Da nun in der Regel viele Clients um nur wenige Threads auf dem Server konkurrieren, kann es schnell zu einer Blockade kommen. Vor allem dann, wenn besonders viele Clients zugleich Operationen auf dem Server durchführen.

Dieses Problem griff Java SE unter dem Namen Non-blocking IO (NIO) erstmals mit der Version 1.4 auf, Java 9 führte es dann weiter. Der Server besitzt nur noch einen Main Thread, der die Verbindungen entgegennimmt und die Operationen, die über das Netzwerk eintreffen, über einen Event-Loop verarbeitet. Eine bestimmte Anzahl von Worker Threads, die über Thread-Pools bereitgestellt werden, kümmert sich dann um eine effiziente Bearbeitung der Operationen.

Die Begrenzung der Geschwindigkeit des Datenstroms zwischen Client und Server ist ein weiteres Thema: Server-Produkte wie Netty oder Undertow implementieren NIO und erweitern es um Features wie das Backpressure-Protokoll. Es ermöglicht, dass Client und Server die Geschwindigkeit des Datenstroms aushandeln können, sodass es zu keiner Überlastung des Servers kommt.

Die Reactive Streams lassen sich nicht nur auf die Thread-Ebene, sondern auch auf die Netzwerk-Ebene übertragen. Beispielsweise kann dann ein Server die Rolle eines Publishers einnehmen und ein Client die Rolle des Subscribers. Der Server bearbeitet fortan die Datenströme und sendet die Ergebnisse über das Netzwerk zurück an den Client. Dieser Ansatz steckt beispielsweise in WebFlux, einem neuen Framework aus dem Spring-Ökosystem. Weitergedacht lässt er sich auch auf Datenbanken, Message-Broker oder andere Middleware-Komponenten ausweiten. Mit R2DBC gibt es bereits eine Spezifikation zu reaktiven Treibern für SQL-Datenbanken, die die klassischen blockierenden JDBC-Datenbanktreiber im reaktiven Umfeld ablösen sollen.

Das schwächste Glied der Kette ist entscheidend

Eine reaktive Architektur ist nur so gut wie das schwächste Glied in der Kette von Architekturkomponenten. Wenn eine Datenbank nicht reaktiv ist, sondern blockiert, dann bleibt auch der Rest der Anwendung stecken. Folglich ist das Übertragen des reaktiven Konzepts auf alle Architekturkomponenten ein wichtiger und notwendiger Schritt.

Die Streaming-Architektur erfüllt die Forderungen aus dem eingangs erwähnten Reactive Manifesto schon weitgehend, und zwar deutlich besser als die bisher betrachteten Architekturstile. Der Fokus dieser Architektur liegt dabei allerdings nicht auf der Server- und Anwendungsebene, sondern vielmehr auf der Daten-, Thread-, und Netzwerkebene. Auf der Datenebene wird ein kontinuierlicher unendlicher Datenstrom vorausgesetzt, so wie das in den Anwendungsfällen vorkommt. Die Kleinteiligkeit der Daten ermöglicht es erst, die Anforderungen aus dem Manifesto zu erfüllen.

Auf der Thread-Ebene wird die Elastizität durch eine Parallelisierung der Operationen erreicht. Dabei spielt ein effizienter Einsatz der Threads die entscheidende Rolle. Effiziente Push-Verfahren ersetzen konventionelle Synchronisierungsansätze der Threads über Polling-Verfahren. Auf der Thread-Ebene spielt Resilienz allerdings eine untergeordnete Rolle, denn die Threads stehen nicht unter Beobachtung und man muss sie im Fehlerfall auch nicht neu starten.

Auf der Netzwerkebene wird die Elastizität durch den Einsatz von NIO erreicht. Damit lässt sich eine große Anzahl von Clients gleichzeitig über das Netzwerk vom Server bedienen, und es lassen sich lange Operationen ausführen, ohne andere Clients zu blockieren. Das Backpressure-Protokoll, über das Clients mit dem Server den Datendurchsatz verhandeln, erhöht die Resilienz, da es kritische Lastsituationen vermeidet.

Ausblick und Fazit

Es gibt nicht „die eine reaktive Architektur“: Jeder der betrachten Architekturstile erfüllt mehr oder weniger gut die Anforderungen aus dem Reactive Manifesto. Somit ist auch eine Cloud-native Architektur reaktiv. Aus der historischen Entwicklung der Architekturstile heraus lässt sich ein interessanter Trend ableiten: Die Anforderungen an Elastizität, Resilienz und Antwortbereitschaft der Anwendungen steigen stetig. Das zwingt die heutigen und zukünftigen Softwarearchitekten, das Potenzial von der Server- bis zur Netzwerkebene besser auszunutzen. Beispielsweise muss der Einsatz von Threads stetig effizienter werden, um die Parallelisierung weiter zu steigern. Um das Potenzial besser ausnutzen zu können, müssen die Dinge offensichtlich immer kleinteiliger werden. Vom Server zu Containern, vom Monolith zu den Microservices, vom Prozess zu den Threads. Diese Entwicklung führt zu zunehmend komplexeren Architekturen.

Die Anwendungsfälle für reaktive Architekturen nehmen zu. Beispielsweise müssen Automobilhersteller ihre Autos vor Cyberangriffen schützen. Dazu senden die Autos alle möglichen Anomalien an einen Server, der diese dann auswertet, mögliche Angriffe identifiziert und die Fahrer warnt. Das ist nur mit reaktiven Architekturen möglich. Da IoT-, Big-Data-, Media-Streaming- und Webanwendungen wachsen, werden die reaktiven Anwendungsfälle in allen Branchen weiter zunehmen.

Das ist auch an der Entwicklung von Programmiersprachen, Frameworks und Middleware-Produkten zu erkennen: Sprachen wie JavaScript, die reaktive Modelle wie die asynchrone und funktionale Programmierung unterstützen, setzen sich stärker durch. Programmiersprachen wie Java nehmen die neuen Programmiermodelle in ihren Sprachumfang auf. Spring Project Reactor, Akka oder Vert.x sind Frameworks, die die Aspekte der reaktiven Programmierung unterstützen und heute zunehmend häufiger anzutreffen sind. Alle bekannten Middleware-Produkte für Datenbanken und Message-Broker bieten bereits reaktive Treiber an. Die Entwicklung reaktiver Systeme erfordert allerdings neue Kompetenzen in vielen Disziplinen der Software-Entwicklung.

Michael Schäfer

ist Principal IT Consultant bei msg. Sein Themenbereich sind Systems of Engagement, sowohl deren technische Umsetzung als auch ihre marktwirtschaftliche Relevanz. Zudem ist er in der Welt von Java und dem Spring-Ökosystem zu Hause.

Literatur:

[1] Geoffrey Moore; System of Engagement and the Future of Enterprise IT; Whitepaper, 2011

[2] Mark Weiser; The Computer for the 21st Century, The Scientific American 9, 1991. Onlineversion: https://ics.uci.edu/~corps/phaseii/Weiser-Computer21stCentury-SciAm.pdf

Update-Hinweis der Redaktion [13.01.2021]:
In der ersten Version des Artikels wurde das Reactive Manifesto den Unternehmen Netflix, Pivotal und Red Hat zugeschrieben. Einige in Reactive Streams involvierte Entwickler haben zwar durchaus diesen Firmenhintergrund, das Manifest stammt jedoch ursprünglich aus dem Scala-Umfeld und der Feder von vier Autoren: Jonas Bonér (Erfinder der Akka-Bibliothek und CTO des Scala-Unternehmens Typesafe), Dave Farley, Roland Kuhn und Martin Thompson.

(sih)