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.