„Ich habe Angst, diesen Service anzufassen“ ist einer der teuersten Sätze im Software-Engineering. Er beschreibt ein System, in dem die Abhängigkeiten unklar sind, der Blast-Radius einer Änderung unbekannt ist und der sicherere Schritt die Lähmung ist. Die meisten Microservice-Teams haben mindestens einen solchen Service — oft den kritischsten.
Was eine Abhängigkeitskarte enthält
Eine nützliche Service-Abhängigkeitskarte beantwortet vier Fragen für jeden Service:
- Was ruft dieser Service auf? (Downstream-Abhängigkeiten)
- Was ruft diesen Service auf? (Upstream-Abhängige)
- Wer besitzt ihn? (Team-Verantwortung)
- In welchem Zustand ist er? (aktiv, veraltet, in Migration)
Zwei Ansätze: Runtime-Discovery vs. explizite Deklaration
Runtime-Discovery verfolgt echten Netzwerkverkehr, um Abhängigkeiten abzuleiten. Akkurat für aktuell aktiven Traffic, aber es fehlen Services ohne Traffic und Metadaten wie Eigentümerschaft oder Status.
Explizite Deklaration bittet Teams, Abhängigkeiten in einer Konfigurationsdatei zu definieren. Das erfordert geringe Wartungsdisziplin, gibt aber Kontrolle: Service-Status, Eigentümerschaft, Tech-Stack — alles, was Runtime-Tools nicht ableiten können.
Für die meisten Teams ist explizite Deklaration der richtige Standard.
Das Hover-Trace-Muster
In einem interaktiven Abhängigkeitsgraphen wird die Impact-Analyse zur Zwei-Sekunden-Operation: Über einen Service hovern, und der Graph hebt sofort seine vollständige Upstream- und Downstream-Abhängigkeitskette hervor. Das verwandelt die Karte von einer Dekoration in ein Werkzeug zur Beantwortung spezifischer Fragen.
Service Map implementiert das out-of-the-box: YAML-definierte Services, interaktives Hover-Tracing, Filter nach Team oder Tech-Stack und teilbare URLs. Self-hosted, statische Dateien, Einmalkauf.
