Die Microservices-Literatur ist reich an technischen Ratschlägen: für Ausfalltoleranz entwerfen, asynchrones Messaging für unkritische Flows nutzen, API-Versionierung durchsetzen, Circuit Breaker implementieren. Das sind solide Praktiken. Aber sie adressieren ein anderes Problem als das, das bei Skalierung den meisten Engineering-Schmerz verursacht.
Das Scale-Threshold-Problem
Microservice-Praktiken, die bei 10 Services funktionieren, scheitern bei 50. Die Symptome sind erkennbar: zunehmende Vorsicht bei Änderungen, längere Incident-Lösungszeiten, Onboarding, das Wochen statt Tage dauert, und das Entstehen von „Wer weiß am meisten über die alten Services“ als kritische Rolle.
Best Practice: Services als Daten definieren
- Jeder Service hat eine YAML-Definition: Name, Team, Stack, Status, Abhängigkeiten
- Die Definition lebt im Repository des Services
- Änderungen an Abhängigkeiten erfordern ein YAML-Update im selben PR
- Die Definitionen speisen eine Visualisierungsschicht, die die Live-Architektur-Map generiert
Service Map übernimmt die Visualisierungsschicht: YAML ein, interaktiver Abhängigkeitsgraph aus. Auf Ihrer Infrastruktur deployed, einmalige Kosten.
