Die Vor- und Nachteile der Architekturstile
Entstanden als digitale Variante des schwarzen Bretts, bieten Mitarbeiter- oder Intranetportale heute einen zentralen, geschützten, einheitlich gestalteten Zugang zu unternehmensinternen Informationen und IT-Anwendungen. Die Einrichtung eines solchen Portals ist alles andere als trivial. Neben der Wahl der Informationen und Apps, die den Mitarbeitern zentral zur Verfügung stehen sollen, ist zu klären, wie das Portal technisch umgesetzt wird. Als Entscheidungshilfe stellen wir hier alternative Portalbaustile in ihrer historischen Entwicklung vor.
Der Klassiker – Portal als Monolith
In der Frühzeit des Internets baute der Webserver die im Browser angezeigte Seite nach jeder Eingabe komplett neu auf. Dies trieb die Netzlast in die Höhe, führte zu Wartezeiten, die Interaktion verlief holprig. Abhilfe schuf das in den Nullerjahren entwickelte Datenübertragungsmodell AJAX (Asynchronous Javascript and XML), das nur geänderte oder zusätzlich aufgerufene Seitenelemente vom Server nachlädt. Dadurch verhalten sich moderne Webapps ähnlich wie lokale Desktop-Software. Mit Technologien wie AJAX wurden Intranetportale ohne spezielle Frameworks als eigenständige Webanwendungen (single web applications, SWA) entwickelt. Die Portalanwendung bildet dabei mit Benutzeroberfläche, Logik und Datenzugriffsschicht eine separate, in sich abgeschlossene Umgebung:
Die SWA vereint Funktionen und Informationen aus Verwaltungs- und Fachabteilungen in einer monolithischen Architektur. Entwickler haben dadurch bei der technischen Umsetzung freie Hand und unterliegen keinerlei architektonischen Vorgaben. Dem stehen jedoch einige Nachteile gegenüber. So fällt beispielsweise ein hoher Implementierungsaufwand an, da jede Funktion von Grund auf realisiert wird. Dabei sind in Absprache mit den Fachverantwortlichen auch ressortspezifische Anwendungsfälle abzubilden. Zudem hängen die Funktionen voneinander ab. Das macht Entwicklung, Wartung und Ausbau gleichermaßen aufwendig. Ist eine Funktion wegen Wartung abgeschaltet, fallen alle anderen Funktionen ebenfalls aus.
Portal 2.0: Form und Inhalt trennen
Um diese Nachteile zu entschärfen, entwickelte man sogenannte Portalcontainer, große Serversysteme, in deren Infrastruktur sich die Apps für die Mitarbeiter implementieren ließen. Außer etwaigen externen Datenquellen laufen dabei alle Apps auf dem Portalserver. Auch die Benutzeroberfläche wird komplett serverseitig berechnet und von dort zum Browser gesendet.
Oberfläche und Anwendungs- oder Businesslogik der am Portal angebotenen Apps werden getrennt voneinander auf dem Softwarestack des Portalservers entwickelt: Elemente der Benutzeroberfläche als wiederverwendbare Portlets, Datenzugriffs- und Logikkomponenten in Form ebenfalls mehrfach nutzbarer, über Standardschnittstellen eingebundener Javabeans. Große Portalserver wie IBM Web-Sphere basieren meist auf der Enterprise-Edition der Java-Plattform (JavaEE).
Den nächsten Evolutionsschritt des Portalcontainers markiert der Einbau einer SOA(= service-oriented-architecture/dienste-orientierte Architektur)-Schicht. Businesslogik und externer Datenzugriff sind hier nicht mehr im Container realisiert, sondern in eine Dienste-Architektur ausgelagert. Aufgerufen werden sie über einen Messagebus oder -broker. Die Portlets greifen nur noch über die standardisierte Schnittstelle des Busses oder Brokers auf die Businesslogik zu. Dieser verteilt die Nachrichten auf die Komponenten der Businesslogik oder speichert sie zwischen, falls eine Zielkomponente nicht erreichbar ist.
Gegenüber einer SWA weisen Portalcontainer mehrere Vorteile auf. Der Portalserver bietet eine Infrastruktur mit Standardfunktionen, darunter Single-Sign-On und Single-Sign-Out beim Portal sowie ein Rollen- und Rechtesystem. Der Server lässt auch die Einrichtung einer einheitlichen Benutzeroberfläche und eines Dashboards zu. In der SOA werden Funktionen aus Backend-Systemen zu operativen Diensten verknüpft. Diese lassen sich per Lastverteilung skalieren und vom einzelnen System ein
Stück weit entkoppeln. Zudem sind sie wiederverwendbar. Mehrere Apps oder komplexere Dienste können sich auf dieselbe SOA-Ressource stützen. Durch ihre Abstraktion in der SOA-Schicht werden Businesslogik und Backend-Funktionen plattformneutral. Dadurch ist es möglich, die SOA-Dienste in verschiedenen Sprachen zu programmieren. Die Kommunikation mit und unter den Diensten läuft über Schnittstellen.
Doch auch Portalcontainer haben Schwächen. Fällt der Container aus, geht das ganze Portal vom Netz/offline. Ausfallsicherheit und Skalierung sind nur durch Vorhalten mehrerer Instanzen des gesamten Servers zu leisten. Vor Zwangspausen schützt die Modularisierung der Apps also nicht. Zwar erleichtert sie die Arbeitsteilung unter den Entwicklern, das Grundgerüst der Portalarchitektur bleibt jedoch monolithisch und damit wenig wartungsfreundlich. Überdies besteht eine starke Abhängigkeit vom Hersteller des Portalservers (Lock-In-Effekt). Dies betrifft zum einen (Sicherheits-)Updates, zum anderen die zwangsläufige Festlegung auf die Programmiersprache der proprietären Schnittstellen des Servers. Die Migration der Apps auf Portalserver anderer Anbieter wird dadurch riskant und äußerst aufwendig. Aus demselben Grund lassen sich bereits vorhandene Anwendungen/Altanwendungen ebenfalls nur mit hohem Aufwand in den Portalcontainer migrieren.
Heute: Leichtbau, aber komplex
Um die Nachteile der immer noch recht monolithischen Portalserver auszugleichen, tendiert man heute zu einer leichteren Architektur auf Basis sogenannter Microservices. Ein Microservice ist eine autarke Software, die einen monofunktionalen Dienst leistet. Durch Verknüpfung beliebig vieler Microservices entstehen multifunktionale Apps. Einmal implementiert, lässt sich ein Service in mehreren Apps einsetzen.
Die Kunst liegt bei der Microservice-Architektur darin, die Services so zuzuschneiden, dass die daraus aufgebauten Apps nicht zu komplex werden. Insbesondere darf die Funktion eines solchen Bausteins nicht zu eng gefasst sein. Vielmehr sollte jeweils ein Service eine abgrenzbare Funktion realisieren. Das Frontend des Portals kann dabei wahlweise auf dem Server oder am Client gerendert werden.
In beiden Fällen werden das Portal, die dort angebotenen Apps und die jeweiligen Oberflächen als eigenständige Module entwickelt. Beim serverseitigen Rendern kommen Webframeworks wie Apache Wicket, JSF oder Spring MVC zum Einsatz. Zum clientseitigen Rendern verwendet man Frameworks auf ECMAScript-Basis wie Angular, React oder Vue. Rendern am Client führt zu einer durchweg schnellen Reaktionszeit der Seiten.
Zu den Stärken der Microservice-Architektur zählen ihre Modularität, Skalierbarkeit, Wartungsfreundlichkeit und Resilienz: Weil Microservices schnell programmiert und wiederverwendbar sind, lassen sich daraus mit geringem Aufwand Apps komponieren, erweitern oder umbauen. Dieser Baustil verträgt sich gut mit einem agilen Vorgehensmodell. Die Services sind unabhängig voneinander skalierbar. In mehreren Apps verwendete oder besonders häufig aufgerufene Bausteine können in mehr Instanzen bereitgestellt werden als selten eingesetzte. Und weil jeder Micro-service nur eine Funktion abbildet, ist er klein genug, um von Entwicklern verstanden, gewartet oder ersetzt zu werden. Die Resilienz der Microservice-Architektur zeigt sich als hohe Verfügbarkeit und Ausfallsicherheit durch Verteilung der Instanzen auf mehrere Server. Das Ausfallrisiko wird bei der Implementierung berücksichtigt. Bei seinem Eintritt springt eine andere Instanz ein, die App läuft weiter. Dank seiner Kapselung kann man theoretisch jeden Microservice in einer anderen Sprache programmieren. Der Datenaustausch unter den Services läuft über standardisierte, sprachneutrale Schnittstellen.
Wie die älteren Portalmodelle, so hat auch die Micro-service-Architektur ihre Schattenseiten. Diese ergeben sich aus der großen Zahl der Services. Gegenüber einem Portalcontainer steigt wegen der Kommunikation zwischen den Services die Netzlast und -latenz. Außerdem nimmt die Komplexität jedes Systems mit der Zahl seiner Komponenten zu. Auch wenn Micro-services separat nutzbare Softwarebausteine bilden, ist es trotzdem erforderlich, sie funktional aufeinander abzustimmen und ihr Zusammenspiel über Schnittstelen zu steuern, eine Interdependenz, die es schon bei der Formulierung der Usecases zu beachten gilt. Der Schnitt der geplanten Apps in Microservices sollte so gewählt sein, dass er die Komplexität des Gesamtsystems minimiert.
Beim Testen, im Echtbetrieb und in der Wartung bereiten auf mehrere Maschinen oder Rechenzentren verteilte Softwareblöcke ebenfalls mehr Aufwand als ein Monolith, der auf einem einzelnen Server läuft.
Unter anderem muss das Zusammenspiel der Micro-services ausgiebig getestet und die Last nach mehreren Parametern auf die Instanzen verteilt werden. Schwierig gestaltet sich auch das Logging und Monitoring: Da jeder Microservice seine Nutzung selbst protokolliert, brauchen die Administratoren Spezialtools wie den ELK-Stack (Elasticsearch, Logstash, Kibana), um sich einen Gesamtüberblick zu verschaffen.
Fazit
Obwohl sich die hier vorgestellten Portalarchitekturen (SWA, Container, Microservices) als Stufen einer Evolution verstehen lassen, sind alle drei noch aktuell. Die Entscheidung für eines dieser Modelle bedarf gründlicher Abwägung, zumal Intranet-Angebote nicht nur immer größer und komplexer werden, sondern auch mehr externe Webressourcen einbinden. Zunächst ist zu klären, welche Informationen und Apps den Mitarbeitern bereitgestellt werden sollen. Danach geht es um die technischen Anforderungen: Mit welcher Grundlast und welchen Lastspitzen ist zu rechnen? Für welche Ausfallrisiken sorgen wir wie vor? Wie weit und wie schnell muss sich die Portallösung skalieren lassen? Wie gut kennt unser IT-Personal einschlägige Modelle, Systeme, Tools? Die Antworten auf solche Fragen sollten sich nicht nur am Status quo orientieren, sondern auch am künftigen Bedarf.
