Kontakt
stefan.bente[at]th-koeln.de
+49 2261 8196 6367
Discord Server
Prof. Bente Personal Zoom
Adresse
Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708 (Wegbeschreibung)
Sprechstunde nach Vereinbarung
Terminanfrage: calendly.com Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail und ich weise Ihnen einen Termin zu.

Themenspeicher für den MEA-Grundlagenteil in SS24

In der fachlichen Grundlagenveranstaltung (5 ECTS) als Bestandteil des WASP1 “Microservices und Event-getriebene Architektur” werden aufbauend auf der Praxiserfahrung im ersten Teil die architektonischen Grundlagen aufgearbeitet und reflektiert, um z.B. “Good Practices” zu erarbeiten, offene Fragen zu analysieren (und möglichst zu beantworten), und bestimmte Aspekte vertieft. Dies kann Architektur-Prinzipien umfassen, aber auch Aspekte wie Skalierbarkeit, Fehlertoleranz, API-Dokumentation, Organisation der Entwicklungsteams und weitere.

Anders als im Praxisteil, wo jede:r Studierende einen eigenen Player entwickelt, gilt im Grundlagenteil:

  • Die Teilnehmer:innen arbeiten in Teams von 2 Personen (im begründeten Fällen alleine oder zu dritt)
  • Es wird auch an den Core-Services gearbeitet (allerdings immer in einem Feature-Branch, nicht auf Main)
  • Die Arbeit muss dokumentiert werden (z.B. im README und/oder einem Feature-Branch der Dungeon-Doku)
  • Es gibt eine Abschluss-Präsentation am Ende des Semesters

Die folgende Themenliste ist vorläufig und kann noch ergänzt werden.

DevOps

(D1) Öffentliches Monitoring-Dashboard für den Dungeon

(Vorschlag Erdinc, eher etwas für 1 Person)

Welches Problem soll gelöst werden?

Es gibt momentan keine öffentlich zugängliche Webseite, auf der man eine Gesamtübersicht über die Infrastruktur des Dungeon sieht. Interessant wäre zentrale Indikatoren zu Traffic, Service Health etc. Dieses Dashboard soll selbsterklärend sein und auch für nicht-technische Personen verständlich sein. Es sollte neben Parametern der Systemauslastung auch ein paar “fachliche” Aspekte übersichtlich zeigen, wie z.B. Anzahl Player, Player Health, Auslastung der einzelnen Services etc.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Konzeption eines solchen Dashboards, aufbauend auf Good Practices aus Literatur und Community, und Implementierung eines Prototyps.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Recherche zu Good Practices: was gehört auf ein solches Dashboard?
  • Ggfs. auch eine Umfrage unter Dungeon-Entwickler:innen und potentiellen Nutzer:innen, um die wirklich relevanten Informationen zu identifizieren.
  • Technologie-Entscheidung: Welche Technologien kommen in Frage? (z.B. Grafana …)
  • Architekturkonzept und -Dokumentation
  • Implementierung eines Prototyps
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

(D2) Log Aggregation und Tracability

Welches Problem soll gelöst werden?

Momentan sind die Logs der verschiedenen Services über verschiedene Systeme verteilt und schwer zu durchsuchen. Wenn es Probleme in den Services gibt, ist es schwer, die Ursache zu finden. In der Praxis verwendet man dafür oft Log-Aggregation-Systeme. Diese führen die Logs aller Services zusammen und ermöglichen eine zentrale Suche.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Konzeption eines solchen Systems, und Implementierung eines Prototyps.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Recherche: wie macht man sowas?
  • Technologie-Entscheidung: Welche Technologien kommen in Frage? Z.B. ELK-Stack (sehr große Lösung), oder auch einfachere Lösungen (wie z.B. Prometheus + Grafana + Loki). (Hier kommt es besonders darauf an, die richtige und handhabbare “Größe” für den Dungeon zu finden, sonst verzettelt man sich ganz furchtbar.)
  • Architekturkonzept und -Dokumentation
  • Implementierung eines Prototyps
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

Architektur

(A1) Event Driven Service Communication

(Vorschlag Daniel & Sascha)

Welches Problem soll gelöst werden?

In der aktuellen Form des MSD verwenden viele Services für die Kommunikation untereinander REST. REST hat zum Vorteil, dass die Kommunikation synchron ist. Das bedeutet, dass der Client eine unmittelbar eine Rückmeldung über die erfolgreiche (oder eben nicht erfolgreiche) Verarbeitung seines Requests erhält.

Auf technischer Ebene erleichtert dies vieles. So kann der Trading Service bei der Ausführung eines Robot-Buy-Commands den Robot Service anweisen eben jenen Robot zu erstellen. Mit der entsprechenden Response des Service kann der Trading Service die Verarbeitung des Commands vollständig abschließen.

Gleichzeitig führt dieser Ansatz dazu, dass die Threads der Services blocken (weil die Implementierung nicht Reactive ist), man darauf angewiesen ist zu jedem Zeitpunkt einen verfügbaren Service erreichen zu können und die Infrastruktur nur schwer bis kaum skalierbar ist (weil ein Puffering fehlt).

Zusätzlich sind die Services nicht so lose gekoppelt wie man sich das wünschen würde. Der Gameservice fungiert zusätzlich als “zentrales Gateway” für die Player, was ihn anfällig macht, ein “Gottservice” zu sein / zu werden.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Die Inter-Service Kommunikation soll vollständig zu einem asynchronen Messaging umgebaut werden. Das bedeutet, dass Services nicht mehr synchron (via REST) miteinander kommunizieren, sondern asynchron über Events. Dies soll zumindest als Konzept beschrieben und in Teilen prototypisch umgesetzt werden.

Die Player würden weiterhin synchrone Commands absetzen, aber dann direkt mit den zuständigen Services kommunizieren. Der Game Service würde nicht mehr als zentrales Gateway für die Player fungieren.

Welche Schritte brauchen wir auf dem Weg dahin?

(tbd.)

(A2) Real Time MSD

(Vorschlag Daniel & Tom, vielleicht eher etwas für 3 Personen)

Welches Problem soll gelöst werden?

Die Taktung nach Runden ist für Microservice-Landschaften “unnatürlich”. In Systemen für z.B. eCommerce ist sowas unbekannt. Es führt zu unnötigen Wartezeiten einerseits, und “lagging Players” andererseits. Wenn man das ändert, dann bedeutet es konkret, dass die Verarbeitung von Events und Commands in Echtzeit erfolgen soll.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Statt einer Gameloop soll der Game Service als Gateway für Player und Endpoint für Commands ein Throtteling pro Robot verwalten - bspw. pro Robot alle 5 Sek. ein Command. Für die Strategie der Player und die Ausführung der Commands bedeutet das First Serve First Come. Ergänzend dazu kann / sollte der Fork eines funktionierenden Players (z.B. MONTE) an das geänderte Spielkonzept angepasst werden.

Am Ende ist ein Konzept und ein in Teilen umgesetzter Prototyp fertig.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Recherche: Findet man Quellen, die sich mit so etwas beschäftigen?
  • Welche neuen Features sind nötig?
    • Locking von Planeten bei Angriffen
    • maximale Zahl von Commands pro Robot und Zeiteinheit
    • …
  • Welche Seiteneffekte können auftreten? (Race Conditions, …)
  • In welchen Repos sind welche Änderungen nötig (bitte detailliert beschreiben)?
    • Core Services Repos
    • DevOps Repos
    • docs-Repo
    • Wie heißt der Feature-Branch?
  • Welcher Player dient als “Showcase” für die Änderungen?
    • Bitte einen der Standard-Player auswählen (MONTE, Hackschnitzel, Legend27)
    • Welche Änderungen sind an diesem Player nötig?
  • Welche Art von automatisierten Tests sind sinnvoll? Wo?
  • Wie und wo wird das Konzept dokumentiert?
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

(A3) Event Authorization in Kafka/Redpanda

(Vorschlag Sascha)

Welches Problem soll gelöst werden?

Die jetzige Architektur des MSD ist in mehrfacher Hinsicht “unnatürlich”, also anders als bei produktiven Microservice-Systemen wie etwa einem eCommerce-System. Die Player leben quasi in einer “Demilitarized Zone” mit dedizierten (Rabbit MQ) Queues, statt direkt am Event-Stream in Kafka/Redpanda teilzunehmen. Der wesentliche Grund dafür ist “Fog of War” - die Player sollen nicht alles sehen, was zwischen den Services und zwischen Services und anderen Playern passiert.

Dies ließe sich ändern, wenn man den Zugriff auf Events in Kafka/Redpanda autorisieren würde. Dann könnten die Player direkt am Event-Stream teilnehmen, und die Services würden die Inter-Service-Kommunikation besonders autorisieren.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Konzept und prototypische Implementierung einer solchen Event-Autorisierung in Kafka/Redpanda.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Welche technische Lösung bieten Kafka/Redpanda an, um Events / Topics zu autorisieren?
  • Wie genau muss sich der Zugriff der Services auf Kafka/Redpanda ändern?
    • Listener-/Producer-Code
    • Konfiguration (Secrets, …)
  • Wie sieht unsere neue Gesamtarchitektur aus, wenn die Rabbit-MQ-Queues wegfallen?
  • Inwieweit muss die Struktur der bisherigen Events überarbeitet werden?
    • Welche Events sind betroffen, welche nicht?
    • Wie halten wir “Fog of War” aufrecht?
    • Welche Events dürfen die Player sehen, welche nicht?
  • In welchen Repos sind welche Änderungen nötig (bitte detailliert beschreiben)?
    • Core Services Repos
    • DevOps Repos
    • docs-Repo
    • Wie heißt der Feature-Branch?
  • Was ändert sich für die Player?
    • Insbesondere: Was geschieht bei der Player-Anmeldung (wenn keine individuelle Queue mehr zugeteilt wird)?
    • Wie ändern sich die Listener in den Playern?
  • Welcher Player dient als “Showcase” für die Änderungen?
    • Bitte einen der Standard-Player auswählen (MONTE, Hackschnitzel, Legend27)
    • Welche Änderungen sind an diesem Player nötig?
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

(A4) “Architekturtests” für Core Services und Player

Welches Problem soll gelöst werden?

Wir sollten einheitliche Qualitätsstandards für den Code unserer Services pflegen. Die Player sollten ebenfalls solchen Standards entsprechen. Ideal wäre es, wenn wir automatisierte Tests hätten, die diese Standards überprüfen.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Konzept und prototypische Implementierung einer solchen Architekturtest-Suite für ausgewählte Core Services und Player.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Recherche: Welche Standards und Prinzipien sind für ein System wie den Dungeon sinnvoll einzuhalten?
  • Welche Anforderungen haben wir an die Architekturtests (z.B. lauffähig in CI/CD-Pipeline, …)
  • Welche Tools gibt es, um diese Standards zu überprüfen? (z.B. ArchUnit, Sonarqube, PMD, …).
  • Welche davon passen für welche Programmiersprache? Gibt es Test-Frameworks, die vernünftig sprachübergreifend funktionieren?
  • Umgang mit “bekannten Problemen” bei den Services, um nicht immer den Build rot zu haben (siehe ArchUnit “Freeze”-Konzept)
  • Implementierung eines Prototyps und Anwendung an einen oder mehrere Services
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

(A5) Dungeon-Dashboard im Microfrontend-Ansatz

Welches Problem soll gelöst werden?

Das existierende Dungeon-Dashboard ist ein monolithischer Client, der via einem eigenen Backend Inputs aus mehreren Core-Services aggregiert und darstellt. Zusätzlich besteht das Problem, dass Backend-Business-Logik im Client implementiert ist (was man daran sieht, dass gewissen Informationen im Client nicht geupdatet werden, wenn der entsprechende Tab nicht im Vordergrund ist).

Dieses monolithische Design passt nicht gut zu einem Microservice-System, bei dem die einzelnen Services möglichst autark sind. Daher soll das Dashboard zu einer Microfrontend-Architektur umgebaut werden. Dabei gibt es nur noch einen “Shell-Client”, der die Microfrontends lädt und anzeigt. Jedes Microfrontend ist einem Core-Service zugeordnet und zeigt Informationen aus diesem Service an, bzw. erlaubt Interaktionen mit diesem Service.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Konzept und prototypische Implementierung eines solchen Microfrontend-Dashboards. Idealerweise haben wir am Ende ein MVP (Minimum Viable Product), das zumindest die wichtigsten Client-Komponenten enthält.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Recherche: Was genau definiert eine Microfrontend-Architektur?
  • Welche technischen Lösungen gibt es überhaupt für Microfrontends?
    • Web Components
    • Dedizierte Frameworks (z.B. Single-SPA, PuzzleJS, Open Components, Qiankun, …)
  • Kriterien für die Technologieauswahl
    • Welche (speziellen) Anforderungen gibt es bei unserem Dashboard?
      • z.B. in welchem Maße interagieren einzelne Komponenten?
      • Siehe auch unten zu den Map Layers
    • Wartbarkeit
    • Developer Experience (DevX)
    • …
  • Ist- vs. Soll-Architektur
    • Wie genau ist die Ist-Architektur des Dashboards?
      • Technologien, Aufbau des Dashboards, Client-Server-Interaktionen, …
      • Bitte als Architekturdiagramm
    • Dasselbe für die Soll-Architektur
  • Technologieauswahl
    • … für die Container-Applikation
    • … für die einzelnen Komponenten
  • Repo-Strategie
    • Wo genau liegt die Container-Applikation (die alle MF-Komponenten aggregiert)?
    • Wo liegen die einzelnen Komponenten? (In den Repos der Core-Services?)
    • Wie funktioniert ein Deployment einer neuen Komponente?
    • In welchen Repos sind welche Änderungen nötig (bitte detailliert beschreiben)?
      • Core Services Repos
      • DevOps Repos
      • docs-Repo
      • Wie heißt der Feature-Branch?
  • Wie stellt man ein einheitliches Look-and-Feel sicher?
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

Player

(P1) Bibliotheken für Player Health Checks

(Vorschlag Robin und Omar)

Welches Problem soll gelöst werden?

Momentan ist es recht schwierig, die “Gesundheit” eines Players zu überwachen. Insbesondere wenn ein Player zu lange für die Verarbeitung der Events und der Berechnung der Kommandos braucht, kommt er in einen “Delusional State” und glaubt sich in längst vergangenen Runden. Wie merkt der Player, dass er “behind” ist, dass Events fehlen und was kann er machen, damit Roboter nicht sinnlose oder fehlerhafte Kommandos abschicken? Die Kommandos, die er absetzt, können ja “zufällig” erfolgreich sein.

Dazu gehört auch die Möglichkeit, den Player-State über definierte Endpoints im verteilten System abzufragen.

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Ziel ist es, in den Sprachen der Player (Java, Kotlin, Typescript, Rust, Python) jeweils eine Bibliothek zu entwickeln, die es ermöglicht, Health Checks zu implementieren - z.B. eine Überwachung der Player Queue.

Inhalt ist ein Konzept und eine prototypische Implementierung, vermutlich nur in 1-2 der Sprachen.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Was definiert “Health” für einen Microservice ganz allgemein?
    • Recherche: Welche Quellen (Bücher, Artikel, Onlinequellen) bieten einen guten Überblick?
      • Standardwerke zu Microservices (z.B. von Newman, Fowler, Richardson, …)
    • Bitte auch über die digitale Bibliothek der Hochschule recherchieren
  • Was definiert “Health” speziell für einen Player (als eine ganz besondere Art Service)?
    • Kein Lagging
    • Kein ausufernder Ressourcenverbrauch (Endlosschleifen, …)
    • Reagiert auf Pings
  • Welche Standard-Endpoints sollte man von den Playern sonst noch abfragen können?
  • Wie kann man einen Player-Health-Check implementieren?
    • No Lagging:
      • Überwachung der Queue (Anzahl Events muss immer wieder auf Null gehen)
      • Aktiver Abruf der aktuellen Rundennummer beim Game Service und Vergleich mit der eigenen eventbasierenden Rundennummer
      • …
  • Vorschlag für eine Standard-API, z.B.
    • /health (z.B. mit JSON-Response)
    • /logs (z.B. mit JSON-Response)
    • …
  • Wo (in welchem Core Service) wird der Player Health abgerufen und angezeigt?
    • Architekturdiagramm
    • Wie und wo kann man das Konzept dokumentieren?
  • Wie kann man das Konzept in den verschiedenen Player-Skeletons implementieren (Java, Kotlin, Typescript, Rust, Python)?
  • In welchen Repos sind welche Änderungen nötig (bitte detailliert beschreiben)?
    • Core Services Repos
    • DevOps Repos
    • docs-Repo
    • Wie heißt der Feature-Branch?
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

(P2) “Pluggable Strategy” und typische Strategy-Patterns

(Vorschlag Robin, vielleicht eher etwas für 1 Person)

Welches Problem soll gelöst werden?

Was sind generelle Strategien zum Steuern der Roboter? Und wie macht man die Strategie austauschbar, und trennt sie von der sonstigen Domänenlogik?

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Recherche nach typischen Strategien, und Entwicklung eines Architektur-Patterns für die Dungeon-Player, um Strategien austauschbar zu machen. Dokumentation in der Dungeon-Doku, und Umsetzung an einem oder mehreren Playern.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Recherche: “Typologie” von Spielen, wie kann man unseren Dungeon dabei einordnen?
    • Welche Quellen (Bücher, Artikel, Onlinequellen) bieten einen guten Überblick?
    • Welche Strategien sind typisch für solche Spiele?
    • Welche Strategien sind für den Dungeon sinnvoll?
      • z.B. “Aggressiv”, “Ressourcen-orientiert”, …
  • Welche Anforderungen gibt es an eine modulare Strategie-Architektur?
    • z.B. leichte Austauschbarkeit
    • Kein Entstehen von “Gottklassen” mit 800 Zeilen und 40 Strategie-Methoden
    • …
  • Was gibt es für Software-Patterns, die es erlauben, Strategien modular und “pluggable” zu machen?
  • Welcher Player dient als “Showcase” für die Änderungen?
    • Bitte einen der Standard-Player auswählen (MONTE, Hackschnitzel, Legend27)
    • Welche Änderungen sind an diesem Player nötig?
    • Gibt es sprach-spezifische Unterschiede bei der Implementierung?
  • In welchen Repos sind welche Änderungen nötig (bitte detailliert beschreiben)?
    • Core Services Repos
    • DevOps Repos
    • docs-Repo
    • Wie heißt der Feature-Branch?
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?

(P3) Besseres Player-Dev-Env

(Vorschlag Moritz, Deniz)

Welches Problem soll gelöst werden?

Die Player-Entwicklung ist momentan noch sehr stark ein Sprung ins kalte Wasser. Wie kann man beim Entwickeln besser unterstützt werden, wie kommt man schneller ins Thema, wie sieht man Fehler besser, welche Automatisierung kann man beim Deployment bereitstellen?

Was ist das Ziel? Was ist am Ende des Grundlagenteils fertig?

Recherche zu typischen Anforderungen an Entwicklungsumgebungen für Microservices, und vielleicht auch eine kleine Umfrage bei Dungeon-Entwickler:innen (und früheren Absolvent:innen …). Konzeption und Konzept und Umsetzung der Verbesserungen, zumindest in Teilen.

Aufnehmen einer “Entwicklungsstrategie” in die Dokumentation, zur Unterstützung bei der Playerentwicklung, so dass man einen Leitfaden direkt am Anfang hat, den man verfolgen kann. Vielleicht auch als Video.

Welche Schritte brauchen wir auf dem Weg dahin?

  • Recherche: Was sind typische Anforderungen an eine Microservice-Entwicklungsumgebung?
    • z.B.
      • schnelle Feedback-Zyklen
      • Debugging-Unterstützung
      • lokale Entwicklungsumgebung
      • …
    • Welche Quellen (Bücher, Artikel, Onlinequellen) bieten einen guten Überblick?
      • Standardwerke zu Microservices (z.B. von Newman, Fowler, Richardson, …)
    • Bitte auch über die digitale Bibliothek der Hochschule recherchieren
  • Umfrage konzipieren
    • Was erleben die teilnehmenden Studies als besonders wichtig?
  • Dokumentationskonzept
    • Wo wird die Entwicklungsstrategie dokumentiert?
    • Was für Formate sind sinnvoll?
  • Besonderer Fokus: Welche Lösung gibt es für “schwache Laptops”?
    • Prozessoren mit < 4 Kernen, < 8 GB RAM
      • typische Ausstattung sollte man auch mal in der Umfrage abfragen
    • Technische Recherche zu möglichen Lösungen
  • In welchen Repos sind welche Änderungen nötig (bitte detailliert beschreiben)?
    • Core Services Repos
    • DevOps Repos
    • docs-Repo
    • Wie heißt der Feature-Branch?
  • Was ist unklar? Was sind offene Fragen? Wo brauchen Sie Feedback oder Hilfe?