Diagnose vor Architektur

Leitfaden · Anbieter-Auswahl

Service-Mesh-Beratung auswählen

Beratung für ein Service Mesh kauft man selten und mit hoher Tragweite: Die Entscheidung wirkt jahrelang in Betrieb, Sicherheit und Team nach. Dieser Leitfaden macht die Auswahl prüfbar: sechs Kriterien, zehn Fragen für das Anbietergespräch und die Signale, bei denen du besser absagst.

Kriterien in Langform

Sechs Kriterien, ausführlich begründet

Diagnose vor Architektur

Zwei Cluster mit identischem Tech-Stack können völlig verschiedene Mesh-Antworten brauchen: andere Traffic-Muster, andere Compliance-Lage, anderes Team. Eine Architektur, die vor der Diagnose entsteht, kann darum nur Zufallstreffer oder Schablone sein. Seriöse Anbieter vermessen zuerst den Ist-Zustand über die relevanten Domänen, von mTLS-Abdeckung und Zertifikatsrotation über Autorisierungs-Policies bis zu Observability und Upgrade-Stand, und leiten daraus ab, was in welcher Reihenfolge zu tun ist. Der Befund gehört schriftlich zu dir: Er ist auch dann etwas wert, wenn du danach einen anderen Anbieter beauftragst.

Festpreis statt Stundenzähler

Ein Tagessatz bepreist Anwesenheit, kein Ergebnis. Bei Infrastruktur-Arbeit ist das doppelt riskant, weil Umwege dort normal sind: ein zäher Rollout, ein unerwarteter Legacy-Dienst, eine Policy, die niemand dokumentiert hat. Beim offenen Tagessatz zahlst du jeden dieser Umwege selbst. Ein Festpreis pro Etappe dreht die Anreize um: Der Anbieter muss vorher verstehen, was zu tun ist, und trägt das Risiko seiner eigenen Schätzung. Kauf Zustände, keine Zeit: „mTLS mesh-weit STRICT, nachgewiesen und dokumentiert" ist ein Zustand. „Zehn Beratertage" ist keiner.

Befähigung statt Abhängigkeit

Der Wert einer Beratung zeigt sich sechs Monate nach ihrem Ende: Kann dein Team das Mesh dann selbst betreiben, erweitern, debuggen? Das passiert nicht von allein, sondern nur, wenn die Umsetzung von Anfang an gemeinsam läuft: dein Team an der Tastatur, der Berater daneben, Entscheidungen im Log, Betrieb in Runbooks. Anbieter, die lieber allein und schnell liefern, erzeugen ein Artefakt, das niemand im Haus versteht, und damit genau die Abhängigkeit, die gute Beratung abbauen soll.

Tool-Ehrlichkeit

Die Mesh-Landschaft ist kein Ein-Produkt-Markt: Istio, Linkerd, Cilium und die Gateway API besetzen unterschiedliche Punkte im Spektrum aus Funktionsumfang, Betriebsaufwand und Team-Anforderungen. Und manchmal ist die richtige Antwort schlicht kein Mesh. Ein Anbieter, der jede Diagnose mit derselben Empfehlung beendet, optimiert seine Pipeline, nicht deine Architektur. Tool-Ehrlichkeit erkennst du daran, dass der Anbieter Fälle benennen kann, in denen er von seinem eigenen Lieblings-Stack abgeraten hat.

Liefertiefe bis Envoy und xDS

Im Normalbetrieb sieht jedes Mesh gleich kompetent aus. Der Unterschied zeigt sich im Vorfall: wenn ein Handshake hängt, ein Retry-Sturm die Latenz frisst oder eine Route nicht greift, obwohl das YAML korrekt aussieht. Dann braucht es Leute, die eine Envoy-Config lesen, einen Config-Dump mit dem Soll vergleichen und xDS-Updates nachvollziehen können. Diese Tiefe lässt sich im Gespräch prüfen: Wer sie hat, erzählt konkrete Episoden mit Werkzeugen und Befunden. Wer sie nicht hat, bleibt bei Architektur-Diagrammen.

Betriebsrealität in regulierten Umgebungen

Wenn dein Betrieb unter Vorgaben wie KRITIS, NIS2, DORA oder BaFin-Anforderungen steht, arbeitet dein Anbieter in einer anderen Welt: Cluster ohne Internetzugang, Freigabeprozesse für jedes Werkzeug, teils sind externe KI-Tools per Policy vollständig untersagt. Beratung, deren Arbeitsweise an frei verfügbare Online-Dienste gekoppelt ist, fällt in diesen Umgebungen aus. Prüfe deshalb, ob der Anbieter souverän auch abgeschottet liefern kann: mit eigener Methodik, eigener Erfahrung und Verfahren, die in einer air-gapped Umgebung genauso funktionieren wie im offenen Netz.

Checkliste

Zehn Fragen an jeden Anbieter vor der Beauftragung

Stell diese Fragen im ersten Gespräch. Es geht weniger um die „richtige" Antwort als um die Reaktion: Seriöse Anbieter freuen sich über präzise Fragen, unseriöse weichen aus.

  1. Welche Befunde erhebst du, bevor du eine Architektur empfiehlst?

    Gute Antworten benennen konkrete Domänen (Verschlüsselung, Autorisierung, Ingress und Egress, Observability, Upgrade-Stand) und ein schriftliches Ergebnisformat. Schwache Antworten springen direkt zur Referenzarchitektur.

  2. Zeig mir eine anonymisierte Referenz-Posture: Wie sieht ein Befund bei dir aus?

    Wer regelmäßig diagnostiziert, kann ein anonymisiertes Beispiel zeigen: Domänen, Bewertungslogik, priorisierte Findings. Wer erst eines bauen müsste, diagnostiziert nicht regelmäßig.

  3. Was heißt bei dir Festpreis: Welcher Zustand ist erreicht, und was passiert bei Mehraufwand?

    Die belastbare Antwort definiert den Zielzustand prüfbar und legt das Schätzrisiko zum Anbieter. „Festpreis, aber Änderungen rechnen wir nach Aufwand" ist ein Tagessatz mit Umweg.

  4. Welche Artefakte bleiben bei mir, wenn wir uns trennen?

    Erwartbar sind: Befund, Architektur-Entscheidungen, Runbooks, sämtliche Konfiguration in deinem Git. Wenn Wissen oder Zugänge beim Anbieter verbleiben, kaufst du eine Abhängigkeit.

  5. Wie befähigst du mein Team konkret, und woran misst du den Erfolg?

    Gute Antworten beschreiben gemeinsame Umsetzung, Reviews und eine definierte Übergabe (etwa: das Team führt das nächste Mesh-Upgrade selbst durch). „Wir machen am Ende einen Workshop" ist zu wenig.

  6. Wie arbeitest du in einer air-gapped oder streng regulierten Umgebung?

    Frag nach konkreten Einsätzen: Wie kommen Images, Charts und Wissen in eine Umgebung ohne Internetzugang? Was ändert sich an der Arbeitsweise, wenn externe Tools, auch KI-Dienste, per Policy verboten sind? Erfahrung zeigt sich hier in Details wie Registry-Spiegelung und Freigabeprozessen.

  7. Was war dein letzter Fund auf Envoy- oder xDS-Ebene?

    Die Antwort trennt Architekten von Betreibern: Wer liefert, erzählt eine konkrete Episode mit Symptom, Werkzeug (Proxy-Logs, Config-Dump, Metriken) und Auflösung. Ausweichen auf „unser Team hat da Experten" ist ein Warnsignal.

  8. In welchen Fällen rätst du von einem Service Mesh ab?

    Jeder seriöse Spezialist hat solche Fälle: kleine Setups ohne Compliance-Druck, Teams ohne Betriebs-Kapazität, Probleme, die ein Ingress löst. Wer keinen einzigen nennen kann, verkauft grundsätzlich.

  9. Wer liefert konkret: Wer sitzt in den Sessions, mit welcher Seniorität?

    Entscheidend ist, dass die Person aus dem Vorgespräch auch liefert, statt an ein wechselndes Junior-Team zu übergeben. Lass dir die Namen und deren Mesh-Erfahrung nennen.

  10. Was passiert nach dem Projekt: Wie wird Drift erkannt, wer plant Upgrades?

    Ein Mesh ist nach dem Rollout nicht fertig. Gute Anbieter haben eine Antwort auf den Betrieb: wiederkehrende Posture-Prüfung, klare Upgrade-Kadenz, definierte Zuständigkeit, mit oder ohne sie.

Warnsignale

Red Flags

Bei diesen Signalen solltest du das Gespräch freundlich beenden:

  • Ein Angebot mit fertiger Architektur liegt vor, bevor jemand deinen Ist-Zustand gesehen hat.
  • Preisauskunft nur als Tagessatz; Etappen, Zielzustände oder Abnahmekriterien kann niemand benennen.
  • Auf die Frage nach Exit-Artefakten gibt es keine klare Antwort, oder Dokumentation ist „im Projektverlauf geplant".
  • Die Tool-Empfehlung steht im ersten Gespräch fest, unabhängig von deiner Lage.
  • Niemand im Liefer-Team kann einen konkreten Envoy- oder xDS-Debugging-Fall erzählen.
  • Wissenstransfer ist ein Punkt „am Projektende, wenn Zeit bleibt", statt Arbeitsweise von Beginn an.
  • Fragen nach regulierten oder abgeschotteten Umgebungen werden mit „das klären wir dann" beantwortet.

Diese Fragen darfst du auch uns stellen

Die spezialisierte Unit unserer Familie, istio-consulting.de, beantwortet alle zehn, im Readiness-Gespräch über deinen konkreten Ist-Zustand.

Readiness-Gespräch anfragen