Talk notes

notes/NOTES.md

@@ -0,0 +1,98 @@
+# Millionen langlebiger TCP-Verbindungen – Herausforderungen und Lösungen bei Update-Prozessen
+
+* Vorstellung ich selbst
+  * Softwareentwickler bei Scandio
+  * ich treibe seit etwa einem Jahr das Thema Softwarearchitektur in der Scandio auf einer fachlichen Ebene voran
+  * Scandio als Spezialistin für Softwareentwicklung im IoT-Bereich
+* Überleitung zum Problem zum Einstieg möglichst zusammenfassen:
+  * Heimdall ist ein Gateway zwischen IoT-Geräten und diversen Backends
+  * Geräte halten eine Websocket-Verbindung, über die mit einem eigenen Protokoll Nachrichten versendet werden
+  * Das Heimdall-System braucht gelegentlich Updates, während derer die Verbindungen nicht gehalten werden können
+  * Bei nicht aktiven Verbindungen können manche Features der Geräte nicht genutzt werden
+  * Daher sollten Neuverbindungen so weit wie möglich vermieden werden
+
+## Inhalt
+
+* Projektsetup (also Hintergrund, Motivation und Ziel des Heimdall-Projekts)
+* Problemstellung (wie oben kurz beschrieben: Verbindungen möglichst selten schließen)
+* Lösungen
+  * die aktuelle statische Architektur des Systems
+  * der Prozess beim Deployment neuer Systemversionen
+  * Wunscharchitektur (wenn Geld und Zeit keine Rolle spielt...)
+
+## Projektsetup
+
+* Heimdall
+  * Woher kommt der Name; ganz kurzer Ausflug in die nordische Mythologie
+  * Gateway zwischen IoT-Geräten und verschiedenen Backends (Zusammenhang zum Namen)
+  * wird seit 2018 entwickelt
+  * löst ein vollständig externes System ab, auf das unser Kunde keinen Zugriff hatte (weder auf Entwicklungsdetails noch auf
+    Source Code etc.)
+* Fachlicher Kontext
+  * Geräte sollen über eine Websocket-Verbindung mit verschiedenen Backends kommunizieren
+  * Die versendeten Nachrichten folgen einem Protokoll, das vom Kunden entwickelt wurde
+  * Insbesondere gibt es verschiedene Nachrichtentypen, die von verschiedenen Backends verarbeitet werden
+  * Heimdall dient als Gateway und Router dieser Nachrichten
+  * umgekehrt sollen auch Backends Nachrichten an die Geräte senden können
+  * auch das geht via Heimdall
+* Qualitätsanforderungen
+  * Verbindungsabbrüche sollen so weit wie möglich verbunden werden, da:
+    * bei fehlender Verbindung manche Features der Geräte nicht genutzt werden können
+    * eine Neuverbindung einen Handshake und diverse andere Prozesse nach sich zieht und somit bei ständigen Neuverbindungen
+      sowohl Heimdall selbst als auch Backend-Systeme überlastet werden könnten
+  * Es sollten wenige Neuverbindungen gleichzeitig stattfinden (der Grund dafür wurde schon oben genannt)
+  * Nachrichteninhalte sollten unverändert weitergegeben und weder modifiziert noch validiert werden
+  * Weder Backends noch die Geräte sollten die Details der Verbindung kennen müssen, um die Schnittstellen nach außen so einfach
+    wie möglich zu halten. Dadurch werden System-Updates einfacher.
+
+## Problemstellung
+* Systemupdate
+  * überleitung vom letzten Satz des vorangegangenen Abschnitts
+  * Logik und Konfiguration muss gelegentlich angepasst werden
+  * Sicherheitsupdates sind teilweise notwendig
+  * Ziel ist, dass in den meisten Fällen hierfür kein Neustart des Systems notwendig ist
+  * Falls Verbindungsabbrüche notwendig werden, sollen die Neuverbindungen möglichst kontrolliert stattfinden, um Überlastungen
+    von Heimdall und den Backends zu vermeiden
+
+## Lösungen
+
+* Architektur Heimdall
+  * [Folie 1]
+    * Das Kernstück von Heimdall ist der "Web Socket Manager", kurz WSM.
+    * Im Wesentlichen öffnet ein Gerät eine Websocket-Verbindung zum WSM. Der WSM leitet die Nachrichten des Geräts an das
+      Backend weiter und umgekehrt werden Nachrichten vom Backend an das Gerät zurückgeleitet.
+  * [Folie 2]
+    * Es gibt allerdings mehrere Instanzen (kurzer Einwurf: "Pod" = "Instanz", wenn man sich mit Kubernetes nicht auskennt) des
+      WSM, die jeweils von einem Load Balancer (Algorithmus: Round Robin) geroutet werden
+    * Bei synchronen Aufrufen an das Backend kommt die Antwort trotzdem an die richtige WSM-Instanz zurück
+    * [Überleitung zu Folie 3] Allerdings sind asynchrone Aufrufe den synchronen vorzuziehen, und Backends könnten auch direkt
+      Nachrichten an Geräte senden wollen
+  * [Folie 3]
+    * Hier kommen der Forwarding-Service (FORS) und eine Adress-Datenbank ins Spiel
+    * Jeder WSM-Pod schreibt nach einer geöffneten Verbindung mit einem Gerät die Geräte-ID zusammen mit der eigenen Adresse in
+      die Adress-Datenbank
+    * Der FORS fragt nun für ein Gerät die richtige Adresse ab und kann Nachrichten vom Backend an die richtige FORS-Instanz
+      weiterleiten
+  * [Folie 4]
+    * Dazu kommt, dass es in Wirklichkeit nicht nur ein Backend gibt
+    * Ein Message Mapping (implementiert als Kubernetes Config Map) kann vom WSM genutzt werden, um zu entscheiden, an welches
+      Backend ein konkreter Nachrichtentyp mit einer konkreten Version gesendet werden soll.
+    * Dieses Mapping ändert sich regelmäßig
+    * Hier ist es daher wichtig, dass eine Rekonfiguration ohne Neustart der WSM-Pods möglich ist.
+  * [Folie 5]
+    * Der WSM hat noch diverse andere Aufgaben
+    * TLS Handshake
+      * Validierung des Client-Zertifikats (ca. 10 Issuer)
+      * bei manchen Issuern soll der Expiry-Timestamp ignoriert werden
+      * manche Client-Zertifikate sollen sofort abgelehnt werden, da die zugehörigen Geräte defekt sind (das wird über eine
+        Datenbank mit blockierten Zertifikaten geregelt; für das Blockieren eines Zertifikats ist ebenfalls kein Neustart
+        notwendig)
+      * manche Geräte sind in Quarantäne und dürfen nur bestimmte Nachrichten versenden (beispielsweise Nachrichten im
+        Zusammenhang mit Firmware-Updates; wie die blockierten Zertifikate wird das über eine eigene Datenbank konfiguriert)
+    * Websocket-Upgrade (also der Protokollwechsel von HTTP zu Websocket)
+    * Corporate Handshake (das ist vom Protokoll des Kunden vorgesehen; vor dem Abschluss dieses Handshakes dürfen keine anderen
+      Nachrichten in beide Richtungen gesendet/weitergeleitet werden)
+  * [Folie 6]
+    * Hier ist noch einmal eine Zusammenfassung des gesamten für uns relevanten Teil des Heimdall-Systems
+* Deployment-Strategie
+  * Wenn ein WSM-Pod kontrolliert beendet wird, werden die Verbindungen zu den entsprechenden Geräten