11. Risks and Technical Debts

Das Volt Portal ist über einen Zeitraum von mehreren Jahren primär durch eine Person technisch entworfen und implementiert worden. Dabei folgt die Grundstruktur im Design immer der Überlegung, wie Funktionalitäten so abstrakt gehalten werden können, dass sie auch für andere Anwendungen, außerhalb der Domäne von Volt Deutschland verwendet werden können.

Daher sind einige strategisch konzeptionelle Entwürfe rudimentär, aber nicht vollständig realisiert, da die Umsetzung für allgemeine Zwecke zu zeitaufwendig gewesen wäre.

Die hier gelisteten technischen Schulden sind in Infrastruktur, Implementierung und Konzept geteilt. Nicht enthalten sind einzelne Anforderungen, die trotz fachlichem Wunsch in ihrer Gesamtheit (noch) nicht im Portal realisiert sind. Innerhalb der Einteilungen sind die technischen Schulden nach Einfluss geordnet.

Infrastuktur

Beschreibung	Erklärung	Bewertung
Es werden mehrere (2 bis 5) Backend-Services (Deploy-Einheiten, vgl. 5.1 Whitebox Overall System) in einem gemeinsamen Task für AWS EC2 definiert. Dadurch können sie nur gemeinsam gestartet, neu geladen und skaliert werden.	Im Mai 2022 wurde das Hosting des Portals zu AWS umgezogen. Dieser Umzug ermöglicht vereinfachte Arbeit, kommt aber mit signifikanten Mehrkosten. Um Geld zu sparen und die pro Task definierten Ressourcen zwischen mehreren Deploy-Einheiten zu teilen, werden sie in einem Task zusammengefasst.	Die Gefahren sind überschaubar, als realistischste Gefahr ist zu beachten, dass bei einem Absturz eines Services alle im Task zusammengefassten Services neugestartet werden müssen. Sofern es die finanziellen Möglichkeiten hergeben, sollte hier zeitnah eine Aufteilung geschehen.
Kondigurationsdateien wie Übersetzungen, URLs externer APIs aber auch Token bzw. Passwörter für die Verbindung mit der Datenbank werden als Umgebungsvariablen über eine Referenz auf eine S3-Datei in der Task-Definition gesetzt.	Auch wenn in AWS Konfigurationsdateien über den AWS Secret Manager abgebildet werden können, sind damit weitere Kosten und Konfigurationsaufwand verbunden.	Der Zugriff auf die S3-Dateien ist durch die Einstellungen in AWS so weit abgesichert, dass kein externer Zugriff erfolgen kann. Personen mit Zugriff auf den AWS Account können aber die im Klartext gespeicherten Konfigurationsn einsehen.
Als Datenbank dient eine AWS RDS MySQL Instanz. Diese ist durch die Einstellung der AWS VPC Security Groups wird der Zugriff von Clients außerhalb des AWS VPC bzw. der in AWS ECS gehosteten Backend-Services verhindert. Muss zur Änderung der DDL oder Analyse einzelner Daten ein manueller Zugriff erfolgen, muss die eigene IP-Adresse temporär freigeschalten werden.	Über ein VPN-Verbindung in die AWS VPC-Umgebung oder einen anderweitig über das Portal getunnelten Zugriff könnte ein kontrollierter Zugriff ohne Veränderung der AWS Konfiguration ermöglicht werden. Aus Zeitgründen wurde das bisher nicht umgesetzt.	Solang keine Zugriffe erfolgen, ist die aktuelle Konfiguration sicherer, als wenn Zugriffsmöglichkeiten über VPN o.Ä. bestehen würden. Allerdings ist die derzeitige Lösung fehleranfälliger, da die Konfiguration nicht nur zunächst manuell geöffnet sondern danach auch wieder geschlossen werden muss. Wird dieser Schritt vergessen, ist die Datenbank (teil)öffentlich erreichbar.
Neue Versionen sind mit der Gitlab CI/CD-Pipeline soweit automatisiert, dass sowohl Backend als auch Frontend versioniert und automatisch in Docker-Images gepackt und in Repositories veröffentlicht wird. Es findet kein automatisches Deployment statt.	Aus zeitlichen Gründen und der zusätzlichen technischen Komplexität durch die oben genannte Zusammenfassung mehrerer Deploy-Einheiten in einen Task wurde das noch nicht umgesetzt.	Es hat keine Auswirkungen auf den Betrieb, kostet aber zusätzlichen (zeitlichen) Aufwand in der Veröffentlichung neuer Versionen.

Implementierung

Beschreibung	Erklärung	Bewertung
Insb. für zeitgesteuerte Funktionen oder z.B. Import-Funktionen die durch Benutzer*innen gestartet werden, müssen Backend-Services miteinander kommunizieren. Um sich gegenseitig auszuweisen ist den Backend-Services ein Token zugewiesen, der sie als maschinelle Akteure ausweist und mit eigenen Rechten Zugriffe auf speziell freigeschaltene Endpunkte ermöglicht.	Als alternatives Pattern wurde eine Event-basierte Struktur in Erwägung gezogen. Für weitere Varianten oder die Umsetzung dessen bestand bisher keine Zeit.	Das Zusammenspiel zwischen individuellen Benutzer*innen und maschinellen Token birgt die Gefahr, dass aus dem eigenen Kontext ausgebrochen und über den maschinellen Token weitere Zugriffsrechte erlangt werden können. Außerdem besteht eine Gefahr dahingehend, dass der Token öffentlich werden und den Zugriff auf geschützte Funktionen ermöglichen kann.
Während das Backend eine ordentliche Abdeckung hat, ist für das Frontend kaum Testing vorhanden. Einzelne Unit-Tests beschränken sich auf zentrale, mehrfachverwendete Funktionalitäten	Da kein entsprechendes Wissen vorhanden ist, wurde zu Beginn kein Testing, insb. kein End-To-End-Testing im Frontend implementiert. Um jetzt ordentliche Tests einzubauen muss das Frontend mit ausreichenden Test-Daten ausgestattet und die Component und End-To-End Tests geschrieben werden.	Da das Frontend keine relevanten Sicherheitsfeatures implementiert besteht keine Gefahr aus Security-Sicht. Allerdings kann es passieren, dass Änderungen dazu führen, dass an unerwarteten Stellen Components nicht mehr wie geplant funktionieren und das erst im Live-Betrieb auffällt.
Das Spenden-Formular ist als einziger Teil aktuell nicht im allgemeinen Frontend eingebunden sondern ein eigenständiges Angular-Project. Dafür gibt es keine Notwendigkeit.	Die doppelte Struktur wurde aus Sicherheitsgründen geschaffen um eine interne und eine externe Linie an Front- und Backend-Implementierungen zu schaffen. Nachdem das Backend bereits zusammengeführt wurde, verbleibt nur das Frontend ohne einen Mehrwert zu bieten.	Es stellt keine Gefahr dar, sorgt aber für Mehraufwand bei Änderungen.
Zeitgesteuerte Funktionen werden aus den Backend-Services heraus ausgeführt und steuern z.B. das regelmäßige Aktualisieren des Namens-Caches oder der Berechnung von Mitgliedsbeiträgen. Dadurch können die Backend-Services nicht mehrfach deployed werden, da ansonsten auch die zeitgesteuerten Funktionen mehrfach ausgeführt würden, die nur als einmaliger Task gestartet werden sollen.	Wie auch zur Lösung von Machine-Tokens ist hier eine Event-basierte Architektur denkbar. Aus zeitlichen Gründen und mangels technischer Notwendigkeit wurde bisher keine Umsetzung priorisiert.	Aktuell besteht kein Bedarf die Systeme mehrfach zu deployen. Aus Skalierungsgründen sollte grunsätzliche aber die Möglichkeit dafür bestehen.
Im Frontend wird eine Mischung aus eigenen Komponenten, Bootstrap, Material und weiteren Frameworks verwendet.		Die uneinheitiche Darstellung kann verwirrend auf Benutzer*innen wirken und schadet einer einheitlichen UX.

Konzept

Beschreibung	Erklärung	Bewertung
Der Onboarding-Service hält eigene Personen-Daten vor und legt damit die Grundlage für Duplikate.	Die Anmeldung von Neu-Mitgliedern ist vollständig in das Onboarding-Modul gekapselt. Hier ist eine niedrigere Security und eine andere fachliche Zuständigkeit gegeben.	Bei der Übernahme von Mitgliedern in den Member- bzw. Person-Service können Duplikate entstehen, wenn der Datensatz bereits für eine*n Spender*in im System vorhanden ist.
Der Onboarding-Service bildet den Prozess des Stellens eines Mitgliedschaftsantrag und der rechtlichen Entscheidung darüber ab. Beim Import des Mitglieds in die Mitgliederverwaltung werden diese Daten dupliziert.	Die Anmeldung von Neu-Mitgliedern ist vollständig in das Onboarding-Modul gekapselt. Hier ist eine niedrigere Security und eine andere fachliche Zuständigkeit gegeben.	Die Zuständigkeiten zwischen Onboarding- und Mitgliedschaft können hier stärker geschärft werden, indem die mitgliedschaftlichen Aspekte der Aufnahme im Mitgliederservice geführt werden.