Seite 2: Softwarearchitektur im historischen Rückblick

Inhaltsverzeichnis

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.