Hybrid-Ops-Lab
Hybrid Operations Lab
Eine reproduzierbare Umgebung für hybride Eventflüsse, kontrollierte Netzwerkstörungen, Monitoring und verifizierte Wiederherstellung.
Ich habe dieses Lab gebaut, um nicht nur über hybride Betriebsmodelle zu sprechen. Es macht sichtbar, wie sich eine schleichende Verbindungsstörung auf Queue, Consumer und Monitoring auswirkt — und wie ein Incident kontrolliert eingegrenzt, stabilisiert und verifiziert werden kann.
- Data Center ↔ Cloud
- Event-driven
- Observable
- Reproduzierbar
Was das Lab zeigen soll
Schleichende Störungen reproduzierbar erzeugen
Entkopplung und Backpressure beobachten
Wiederherstellung nicht nur annehmen, sondern verifizieren
Das Ziel ist nicht, dass nichts ausfällt. Das Ziel ist, dass wir erkennen, was passiert, die Auswirkung begrenzen und kontrolliert wiederherstellen können.
Architektur
Die Darstellung basiert auf dem tatsächlich implementierten Lab. Idempotenz, Deduplizierung und eine Producer-Outbox werden bewusst nicht behauptet.
Data-Center-Seite (site-dc)
- Inventory Service (FastAPI) mit Publisher
- PostgreSQL als Source of Truth
- node_exporter
Cloud-Seite (site-cloud)
- ElasticMQ als SQS-kompatible Queue
- Consumer auf k3d (Kubernetes)
- Prometheus, Grafana, Alertmanager, Blackbox Exporter
- node_exporter
Hybrid-Strecke
Toxiproxy sitzt als Container auf dem Netzwerkweg zwischen Queue und Consumer. Im Normalbetrieb leitet er die Verbindung weiter. Für das Degradation-Szenario erhöht er gezielt die Latenz auf dem Consumer-Leseweg.
Der Eventfluss
- Inventory / Publisher
- ElasticMQ Queue
- Toxiproxy
- Cloud Consumer
- Der Publisher legt Events in der Queue ab.
- Die Queue entkoppelt Erzeugung und Verarbeitung.
- Der Consumer liest über Toxiproxy.
- Erfolgreich verarbeitete Nachrichten werden anschließend aus der Queue entfernt.
- Bei langsamer Verbindung sinkt der Lesedurchsatz und die Queue-Tiefe steigt.
Das Lab in 60 Sekunden
Der Ablauf ist reproduzierbar: Umgebung starten, Events erzeugen, Latenz injizieren, Auswirkungen beobachten und die Wiederherstellung verifizieren.
-
Starten
Lab-Komponenten und Monitoring hochfahren.
make up -
Belasten
Einen kontrollierten Eventfluss erzeugen. Die Inventory-App nimmt Lagerbewegungen über
POST /movementsentgegen und publiziert daraus die Events in die Queue. Für die Demo werden mehrere solcher Bewegungen erzeugt. -
Stören
Latenz über Toxiproxy auf dem Consumer-Leseweg injizieren.
make demo-incident -
Wiederherstellen und prüfen
Latenz entfernen, Backlog beobachten und den End-to-End-Fluss verifizieren.
make demo-restore make check
Der Incident
-
Detect
Das Signal wird erkannt, bevor etwas ausfällt.
- Latenz auf dem Consumer-Leseweg steigt.
- Queue-Tiefe beginnt zu wachsen.
- Monitoring erkennt die Abweichung.
-
Assess
Die Auswirkung wird eingegrenzt, statt blind zu handeln.
- Publisher, Queue und Consumer bleiben verfügbar.
- Consumer ist healthy, verarbeitet aber langsamer.
- Blast Radius auf die gedrosselte Strecke eingegrenzt.
-
Decide
Ursache vor Symptom — keine vorschnellen Eingriffe.
- Keine pauschalen Restarts, kein Symptom-Aktionismus.
- Queue und Consumer weiter beobachten.
- Strecke isoliert untersuchen.
-
Mitigate
Stabil halten statt hektisch verändern.
- Die Queue puffert die noch nicht verarbeiteten Events.
- Eventfluss bleibt nachvollziehbar.
- Keine unnötige Veränderung während des Incidents.
-
Recover
Die Strecke ist zurück, der Rückstau wird abgebaut.
- Zusätzliche Latenz wird entfernt.
- Consumer arbeitet den Backlog ab.
- Queue-Tiefe fällt kontrolliert auf null.
-
Verify & Learn
Erst nach geprüftem End-to-End-Fluss abgeschlossen.
- Queue leer, Consumer healthy, Strecke stabil, Alert geschlossen.
- Timeline und Ursache sichern, Schwellenwerte und Runbook prüfen.
- At-least-once, mögliche Mehrfachzustellung und Producer-Retry/Outbox als Hardening-Themen bewerten.
Sichtbare Belege
StreckeDegraded; eine zweite Regel StreckeDown deckt den
vollständigen Ausfall ab.
Ein dedizierter Recovery-Screenshot liegt aktuell nicht vor und wird hier bewusst nicht nachgestellt. Der Wiederherstellungs- und Verifikationsablauf ist im Abschnitt „Der Incident" beschrieben.
Architekturentscheidungen (ADRs)
Kompakt zusammengefasst aus den ADRs des Repositories.
ADR-001Lokale Demo statt echter AWS-Umgebung
Ausgangslage: Der Showcase soll für Dritte nachvollziehbar sein — klonbar, ohne Credentials lauffähig, ohne laufende Kosten. AWS nutze ich beruflich täglich; das muss ein privates Projekt nicht erneut belegen.
Entscheidung: Die Demo läuft vollständig lokal auf zwei VMs; AWS-Dienste werden, wo nötig, durch einen lokalen Emulator ersetzt. Der OpenTofu-Code nutzt einen konfigurierbaren Endpoint und bleibt AWS-portabel.
Warum: Ohne Konto startbar, keine Kosten und keine vergessenen Ressourcen; der IaC-Code könnte gegen ein echtes AWS-Konto laufen.
Bewusste Grenze: Kein echtes IAM, keine echten Service-Quotas; ein Emulator verhält sich unter Last nicht wie AWS. Die Demo zeigt Prinzipien und Vorgehen, nicht Skalierung.
ADR-002Zwei VMs statt einer Maschine
Ausgangslage: Auf einer einzigen Maschine wäre die Standortgrenze nur eine Namenskonvention — es gäbe keine echte Netzwerkstrecke, die degradieren kann. Genau diese Strecke ist in Hybrid-Umgebungen der kritische Punkt.
Entscheidung: Beide Standorte laufen als getrennte VMs mit eigenen OS-Instanzen und IP-Adressen auf demselben Proxmox-Host. Die Trennung ist logisch, nicht physisch.
Warum: Es existiert eine echte, beobacht- und störbare Netzwerkstrecke; jede Site hat einen eigenen Lebenszyklus.
Bewusste Grenze: Keine physische Redundanz — ein Host-Ausfall trifft beide Sites; etwas höherer Ressourcenbedarf. Für den Demo-Zweck akzeptiert.
ADR-003Toxiproxy als simulierte Standortverbindung
Ausgangslage: Das zentrale Szenario ist eine Degradation der Verbindung zwischen den Standorten. Eine normale Netzwerkverbindung bietet dafür keinen sauberen Hebel.
Entscheidung: Der Verkehr zwischen site-dc und site-cloud läuft durch Toxiproxy. Die Strecke wird damit zu einem steuerbaren Objekt: Latenz, Paketverlust und Ausfall lassen sich per API reproduzierbar schalten.
Warum: Reproduzierbare, skriptbare Störungen für definierte Incident-Übungen; SLA-Schwellen lassen sich gezielt testen.
Bewusste Grenze: Toxiproxy arbeitet auf TCP-Ebene — kein echtes Routing, kein BGP, keine Layer-2-Effekte; zusätzlich ein bewusst akzeptierter Single Point of Failure auf dem Datenpfad.
ADR-004Proxmox-Provisionierung der Lab-VMs
Ausgangslage: Die VMs brauchen einen reproduzierbaren, prüfbaren Stand. Manuelles Klicken widerspricht dem deklarativen Anspruch; die private Virtualisierung darf nicht nach außen exponiert werden.
Entscheidung: VMs per OpenTofu (Provider bpg/proxmox) als Full-Clone eines Ubuntu-24.04-Templates; Cloud-Init für Sizing, IP und SSH-Keys; dedizierter API-Token; umgebungsspezifische Werte nur in einer ignorierten Variablendatei. Host-Setup über idempotente Bootstrap-Skripte; apply nur aus kontrollierter Umgebung, CI auf fmt und validate beschränkt.
Warum: Versionierter, reproduzierbarer VM-Stand ohne Secrets im Repository und ohne Exposition der Management-API.
Bewusste Grenze: Im Lab nutzt der Token zur Vereinfachung weite Rechte; produktiv gilt least-privilege mit Rotation und Ablaufdatum.
ADR-005ElasticMQ statt LocalStack als SQS-Endpoint
Ausgangslage: site-cloud braucht einen lokalen, SQS-kompatiblen Endpoint. LocalStack erfordert seit dem 23.03.2026 einen Account/Token — das widerspricht dem Prinzip „lokal, autark, keine Secrets" (ADR-001).
Entscheidung: site-cloud nutzt ElasticMQ (softwaremill/elasticmq, gepinnt auf 1.6.16) als SQS-Endpoint — zweckgebunden, ohne Account/Token, mit echtem HTTP-Endpoint hinter Toxiproxy.
Warum: Die App bleibt unverändert (SQS_ENDPOINT_URL ist bereits Variable); keine externe Abhängigkeit und kein Secret im Lab.
Bewusste Grenze: ElasticMQ kann nur SQS — bei weiteren AWS-Diensten ist diese Entscheidung neu zu bewerten; Queue-URLs müssen für Cross-Site-Zugriff konfiguriert werden.
Bewusste Grenzen
- ElasticMQ ist ein lokaler SQS-kompatibler Emulator, kein produktiver AWS-SQS-Service.
- Es gibt keine Producer-Outbox und keinen automatischen Replay-Mechanismus.
- Idempotenz beziehungsweise Deduplizierung ist nicht implementiert.
- At-least-once kann Mehrfachzustellung bedeuten.
- Das Lab bildet gezielt ein Szenario ab und ist keine vollständige Enterprise-Plattform.
- Der Live-Betrieb läuft auf einem privaten Homelab als Demonstrationsumgebung.
Die Grenzen gehören für mich zur Architektur. Ich dokumentiere nicht nur, was funktioniert, sondern auch, was für einen produktiven Ausbau noch fehlt.
Vom statischen Nachweis zur Live-Demo
Das Lab läuft auf meiner eigenen Proxmox-Umgebung. Eine abgesicherte Live-Ansicht von Grafana über Cloudflare Tunnel und Zero Trust ist als nächster Erweiterungsschritt vorgesehen.
Die statischen Belege auf dieser Seite bleiben unabhängig von der Verfügbarkeit des Homelabs nutzbar.
Nicht nur gebaut, sondern verstanden
Für mich endet ein technischer Showcase nicht damit, dass Container laufen und ein Dashboard grün ist. Entscheidend ist, ob ich das Verhalten unter Störung erklären, meine Entscheidungen begründen und die Grenzen der Lösung offen benennen kann.