Mit dem Projekt newweb@be wird beim Kanton Bern eine wichtige Grundlage für die digitale Zukunft gelegt. In einem ersten Schritt erscheint die Webseite des Kantons in neuem Gewand auf einer modernisierten Plattform. Darauf basierend wird die Digitalisierung von Geschäftsvorgängen vorangetrieben.
Vision newweb@be
Der neue Webauftritt soll mit einem responsiven Design, einer schlanken Inhaltsstruktur und durchgängiger Access4All-Zertifizierung eine ansprechende und intuitive Benutzerführung ermöglichen.
Um diese erste Phase erfolgreich abzuschliessen, hätte man die Umsetzung dieses Projekts durchaus nach klassischen Mustern mit einer monolithischen CMS-Applikation realisieren können. Allerdings geht die Strategie des Kanton Bern deutlich weiter. Deshalb ist es wichtig, bereits früh ein System aufzubauen, welches für zukünftige Anforderungen und Bedürfnisse eine optimale Basis bietet.
Qualitätsmodell für moderne Webapplikationen
Um eine geeignete Plattform zu erstellen, ist es wichtig zu verstehen, welche Ansprüche an aktuelle und zukünftige Webapplikationen gestellt werden. Denn die Qualität hat einen zentralen Einfluss auf das Systemdesign. Dabei meint Qualität nicht einfach nur die Güte der Implementation oder Umsetzung, sondern weitere Aspekte, welche wir im Folgenden etwas genauer anschauen wollen.
Leistungsfähigkeit
Die Leistungsfähigkeit ist für heutige Systeme ein zentrales Qualitätsmerkmal. Leistung zeichnet sich durch schnelle Antwort- und kurze Übertragungszeiten aus. Bei Webshops hat sich gezeigt, dass die Performance grossen Einfluss auf die Konversionsrate hat. Diese Erkentnisse lassen sich direkt auf ein Publikationssystem übertragen. Auch hier ist die Akzeptanz durch den Benutzer deutlich grösser, wenn er die gesuchten Information schnell erhält.
Eine gute Performance zeichnet sich durch folgende Merkmale aus:
Verarbeitungsgeschwindigkeit von Anfragen
Latenz der Übertragung von Anfragen und Antworten
Skalierbarkeit
Auch die Skalierbarkeit eines Systems ist ein wichtiger Faktor, um Lastspitzen optimalerweise automatisiert abzufangen. Bei herkömmlichen Lösungen bedingt eine Skalierung meist, dass zusätzliche Server oder virtuelle Maschinen aufgebaut und integriert werden müssen. Moderne Lösungen teilen die verfügbare Kapazität auf die vorhandenen Dienste auf. Wird ein Dienst überdurchschnittlich beansprucht, können automatisch zusätzliche «Container» gestartet werden, welche beim Bearbeiten der Anfragen mithelfen. Werden beispielsweise nachts weniger Anfragen ausgelöst, können die Container ebenfalls automatisiert gestoppt und somit Ressourcen gespart werden.
Verfügbarkeit
Die Verfügbarkeit eines Systems ist für den Kunden das offensichtlichste Qualitätsmerkmal. Ist ein Webauftritt nicht verfügbar, fällt dies sofort negativ auf. Deshalb müssen Webapplikationen horizontal skaliert und verteilt betrieben werden können.
Veränderbarkeit
Damit schnell auf neue Bedürfnisse oder Sicherheitsrisiken reagiert werden kann, muss ein modernes Websystem einfach angepasst, erweitert oder aktualisiert werden können. Aus diesem Grund werden Systeme in ihre verschiedenen Domänen aufgeteilt, welche eine möglichst lose Kopplung untereinander haben. Dadurch ist es möglich, einzelne Systemfragmente anzupassen, ohne einander zu beeinflussen. Diese Art des Systemaufbaus fand ihren Anfang in den sogenannten SOA (Service Oriented Architecture) und wurde später zur Microservice-Architektur weiterentwickelt. Bei monolithisch aufgebauten Systemen hingegen, muss für eine Anpassung jeweils das komplette System getestet und neu ausgerollt werden.
Sicherheit
Die Sicherheit einer Webapplikation ist wie die Verfügbarkeit ein Qualitätsmerkmal, welches sehr stark nach aussen wirkt. Eine bekannt gewordenes Sicherheitsproblem hat dabei einen äusserst negativen Einfluss auf den Ruf einer Organisation. Es gilt nicht nur die Benutzerdaten zu schützen, sondern auch die Integrität der publizierten Daten zu gewährleisten.
Historie vs. moderne Webarchitekturen
Diverse Projekte mit dem Content-Management-System AEM der Firma Adobe, darunter auch das kantonale CMS08, haben gezeigt, dass die Wartbarkeit von AEM als monolithisches CMS sehr aufwändig und komplex ist. Dies ist zu einem Teil durch AEM selbst verschuldet. Es hat aber auch damit zu tun, wie vor über zehn Jahren Projekte umgesetzt wurden. Zu dieser Zeit war die Serverinfrastruktur ein massgeblicher Teil der Gesamtinvestition. Deshalb wurden Umsysteme und Services direkt in das CMS integriert, um damit Kosten für Hardware zu reduzieren.Historisch bedingt bietet AEM praktisch alles, was es braucht, um eine Homepage zu betreiben. Allerdings haben sich die Anforderungen an Webapplikationen in den letzten Jahren drastisch geändert. Seitens Besucher wird erwartet, dass die Webseiten und die damit verbundenen Dienste rund um die Uhr verfügbar sind und auf verschiedenen Endgeräten schnell und zuverlässig funktionieren. Ausserdem stellt die Integration der Fachapplikationen ganz neue Anforderungen an ein System.Bei diesen gestiegenen Anforderungen stösst AEM an seine Grenzen:
Das Digital Asset Management (DAM) ist nicht dafür ausgelegt, Bilder schnell und in der passenden Grösse zur Verfügung zu stellen. Für neue Renditions müssen jeweils Workflows über den gesamten Datenbestand ausgeführt werden.
Die AEM-interne Suche wurde bereits früher durch externe Systeme abgelöst. Auch im Projekt newweb@be soll sie mit einer externen Lösung realisiert werden.
Die Integration des Frontend oder der Umsysteme in AEM reduziert die Änderbarkeit des Systems aufgrund der starken Kopplung: Erfolgt eine Änderung am Frontend oder einem integrierten Dienst, kann nicht nur dieser Code angepasst werden. Frontend und Dienste müssen wieder in AEM integriert werden. Das verursacht einen erhöhten Aufwand bei der Entwicklung und einen massiven Aufwand beim Testing.
AEM selbst kann nicht in nützlicher Zeit skaliert werden. Das System muss von Beginn an auf Lastspitzen ausgelegt werden. Das führt zu höheren Kosten bei Hosting und den Lizenzen. Eine Redundanz des Autoren-Systems ist nur über Umwege mit einer Primary-Replica-Konfiguration erreichbar und anfällig auf Inkonsistenzen.
In AEM sind alle Daten und Programme im gleichen Repository und können nicht getrennt werden. Somit muss bei einem Produkt-Upgrade jeweils die gesamte Datenhaltung aktualisiert werden. Da AEM als Repository die Eigenentwicklung Jackrabbit-Oak einsetzt, muss bei einer Systemgrössen von 0.5TB in der Regel mit Durchlaufzeiten zwischen 4 bis 12 Stunden gerechnet werden, je nach dem wie aufwändig die Migrationsoperationen sind.
Eine Integration der Umsysteme in AEM bedeutet, dass der Requestpool für all diese Umsysteme auch geteilt wird. Das macht die gesamte Webapplikation für DDoS-Attacken anfällig. Insbesondere dann, wenn komplexe Dienste integriert werden.
Der Markt für CMS und dazugehörige Umsysteme, wie zum Beispiel die Suche oder das Asset Management, hat sich diesen Anforderungen angepasst. Diese Funktionen können als Software as a Service (SaaS) direkt von Cloud-Anbietern bezogen werden. Diese Dienste bieten bezüglich Funktion, Preis und Verfügbarkeit meist ein Vielfaches mehr als bei klassischen CMS. Ausserdem verfügen die meisten Dienste standardmässig über ein Content Delivery Network (CDN). Damit können Inhalte global mit geringer Latenz zur Verfügung gestellt werden. Zusätzlich kann die Systemlast signifikant reduziert werden. Um die Dienste zu integrieren, ist oft nur noch wenig Programmierung notwendig. Auch der Konfigurationsaufwand ist normalerweise gering.Für monolithische Applikation sprechen unterdessen nur noch sehr wenige Argumente. Üblicherweise wurde an dieser Stelle die aufwändige Orchestrierung der zahlreichen separaten Dienste aufgeführt. Dieses Problem wurde aber mit Docker und Kubernetes entschärft und die Beziehungen können über relativ einfache Konfigurationen abgebildet werden. Auch die Sicherheit wird an dieser Stelle oft erwähnt, da dieser Aspekt bei jedem einzelnen Dienst beachtet werden muss. Allerdings kann bei einem einfach veränderbaren System viel schneller auf Sicherheitslücken reagiert werden, als bei einem monolithischen System. Hier hat also lediglich eine Problemverlagerung stattgefunden.
Systemarchitektur newweb@be
Mit der Vorgabe AEM einzusetzen, stellte sich die Herausforderung, eine Plattform aufzubauen, welche heutigen Qualitätsansprüchen gerecht wird. Deshalb integrieren wir diesen monolitischen Kern in eine Microservice-Plattform.Dies bewog uns zu zwei zentralen Entscheidungen: Zum einen wird AEM als Headless-System betrieben. Dies erlaubt einen autonomen Betrieb der Frontend-Applikation. Des Weiteren wird neben dem CMS auch ein Kubernetes Cluster bereitgestellt, welcher für die einzelnen Applikationen ausserhalb des CMS als Laufzeitumgebung dient. Damit ist es möglich, die verschiedenen Themen separat anzugehen. Änderungen in diesen Domänen können vorgenommen werden, ohne andere Systemfragmente zu beeinflussen.
Die ersten Applikationen welche in Kubernetes betrieben werden sind folgende:
Die Frontend-Applikation, welche für die Präsentation zuständig ist.
Der News-Service, da diese Domäne eine deutliche höhere Anforderung an die Verfügbarkeit hat, als mit einem einzelnen Autoren-System bei AEM möglich ist.
Die Integration des Kantonalen KeyCloak-Dienstes (Identity Provider), welcher die Authentifizierung und Authorisierung der Redaktoren übernehmen wird.
Bereits jetzt sind weitere Integrationen und spezifische Lösungen für die verschiedenen Ämter geplant. Durch die Microservice-Architektur ist es möglich, diese Vorhaben isoliert und mit sehr geringen Nebenwirkungen umzusetzen. Somit können sie in deutlich kürzerer Zeit auf der neuen Plattform aufgeschaltet werden.
Kosten und Wirtschaftlichkeit
Für den Betrieb der neuen Plattform wird ein ähnlicher Hardware-Bedarf wie für das alte System nötig sein. Dies ist aber in Anbetracht der höheren Leistungsfähigkeit durchaus angemessen. Weiter wird die Plattform georedundant ausgelegt, was gegenüber des bisherigen CMS08 einen Vorteil bezüglich Zuverlässigkeit und Ausfallsicherheit bedeutet.
Neu wird die Präsentation sowie die Service-Integration nicht mehr in AEM umgesetzt. Deshalb sind für den Zielzustand des Systems weniger AEM-Publisher-Instanzen vorgesehen als bisher (zwei statt wie bisher vier). Mittelfristig ist mit einer Kosteneinsparung zu rechnen, da die AEM-Lizenzen einen wesentlichen Teil der Betriebskosten ausmachen.
Weiterentwicklung und Wartung
Da AEM bei der neuen Plattform deutlich schlanker gehalten wird, dürften zukünftige Produkte-Upgrades wesentlich geringere Kosten verursachen. Das Budget kann entsprechend entweder gespart oder in die Erweiterung des Systems und somit in die weitere Digitalisierung der Geschäfte des Kantons investiert werden.Weiter ist es dank Kubernetes möglich, das Deployment von neuen oder aktualisierten Applikationen praktisch vollständig zu automatisieren. Ebenfalls erlaubt diese Technologie unterbruchfreie Deployments. Das führt zu höherer Verfügbarkeit und ist deutlich kostengünstiger, als die bisher sehr aufwändigen Installationen und Upgrades bei AEM. Auch Teile des AEM-Deployments werden weiter automatisiert, um Downtimes sowie Migrationsaufwand zu minimieren.Auch das automatisierte Testing ist ein zentrales Thema bei der Entwicklung der Plattform. Durch die Automatisierung können Releasezyklen deutlich verkürzt, respektive im Optimalfall komplett aufgebrochen werden. Ausserdem fällt zukünftig deutlich weniger Aufwand durch manuelles Testing an.
Ausblick
Mit einer Plattform, welche einfach und zeitnah erweitert werden kann, wird der Grundstein für die weitere Digitalisierung der Geschäftsprozesse beim Kanton gelegt. Geschäftsvorgänge können so präzise und benutzerfreundlich abgebildet und mit den entsprechenden Fach-Applikationen integriert werden. Durch die direkte Integration sind weniger manuelle Schritte notwendig, was den Verwaltungsaufwand und mögliche Fehlerquellen minimiert.
Quellenangaben
Qualitätsmodell basierend auf dem Buch «Architektur für Websysteme» von Daniel Takai
Kontakt für Ihre digitale Lösung mit Unic
Termin buchenSie möchten Ihre digitalen Aufgaben mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus: Jörg Nölke und Gerrit Taaks (von links nach rechts).
Wir sind da für Sie!
Termin buchenSie möchten Ihr nächstes Projekt mit uns besprechen? Gerne tauschen wir uns mit Ihnen aus: Melanie Klühe, Stefanie Berger, Stephan Handschin und Philippe Surber (im Uhrzeigersinn).
