@@ -28,4 +28,46 @@ Damit trennen wir fachliche Logik (Core, Agents) von Basisdiensten (Messaging, D
### Kommunikationsmuster
- Agents <-> Core: Die Kommunikation ähnelt dem RPC-Pattern einfach über NATS. Die Agents senden einen Request und der Core antwortet darauf. Der Core imitiert keine Kommunikation.
- Core <-> Postgres: klassisches Read/Write mit DB-Connection
- Logging: Promtail sammelt Container-Logs und pusht sie an Loki. Grafana visualisiert die Daten über Loki als Datasource (ausführlichere Beschreibung hier zu finden :link: LINK :red_circle:).
\ No newline at end of file
- Logging: Promtail sammelt Container-Logs und pusht sie an Loki. Grafana visualisiert die Daten über Loki als Datasource (ausführlichere Beschreibung hier zu finden :link: LINK :red_circle:).
## :red_circle: ???
### Warum verteilte Architektur?
- Trennung von Verantwortlichkeiten:
- Core ist der zentrale Business Logic Server
- Agenten sind kleine, isolierte Take, die unabhängig voneinander skalierter und austauschbar sind.
- Lose Kopplung: Kommunikation über NATS entkoppelt Agents und Core zeitlich und organisatorisch.
- Erweiterbarkeit: Neue Agenten können hinzugefuegt werden ohne Core anzupassen.
- Resilient: Fällt ein Agent aus, bleiben die anderen lauffähig – Core beleibt stabil.
### Warum GitOps mit Fleet?
- Nachvollziehbarkeit: Jede Änderung im Cluster als Commit im Git-Repo nachvollziehbar.
- Abhängigkeiten steuerbar: Es wird sichergestellt, dass zB, der Core erst startet, wenn Postgres und NATS bereitstehen.
- Multi-Namespace & Multi-Cluster fähig: Struktur kann problemlos auf grössere Umgebungen erweitert werden.
## Mehrwert für das Business
- Schnellers Onboarding: Neue Entwickler oder Betreiber verstehen sofort, welche Komponenten wo laufen
- Stabilität & Qualität: Fehler in der Infrastruktur wirken sich nicht chaotisch auf alle Services aus, sondern sind klar isoliert.
- Agilität: Agenten koennen unabhängig voneinander deployed oder aktualisiert werden – kürzere Entwicklungszyklen.
- Observability einbgebaut: Logs sind zentralisiert via Loki/Grafana. Auch wenn Prometheus fehlt, ist das System schon recht gut beobachtbar.
## Erweiterbarkeit (Beispiel zu Monitoring)
Ein grosser Vorteil der Architektur ist die einfache Erweiterbarkeit:
- Prometheus/Alertmanager oder OpenTelemetry Collector koennen analog zu Loki/Grafana als eigene Bundles im Namespace monitoring hunzugefuegt werden.
- Dank GitOps genügt ein zusätzlicher Eintrag im Repo (`gitops/infra/monitoring/prometheus`), und Fleet übernimmt das Deployment und die Steuerung.
- Keine strukturelle Änderungen nötig: Die Monitoring-Komponenten wären genauso lose gekoppelt wie heute Loki/Promtail.
Damit Zeigt sich: Auch wenn Monitoring aktuell nur Logging abdeckt, ist ide Erweiterung auf Metric/Tracing ohne Bruch und möglich und weitestgehend darauf ausgelegt.
## Zusammenfassung
- Die Architektur trennt fachliche Logik, Infrastruktur und Steuerung klar voneinander.
- Durch GitOps mit Fleet haben wir eine automatisierte, reproduzierbare Deployment-Pipeline.
- Fachliche profitieren wir von Entkopplung, Erweiterbarkeit und Transparenz.
- Der Aufbau ist zukunftssicher: zusätzliche Monitoring-/Tracing-Komponenten können problemlos integriert werden.
- :red_circle: Das alles hilft dem Unternemen stabile und einsehbare Deployments and die Kunden auszuliefern.
