Sidecar-Prozess

Große Internetdienste bestehen heute aus vielen kleinen Programmen, die zusammenarbeiten. Jedes dieser Programme hat eine klare Aufgabe, etwa Bestellungen annehmen oder Preise berechnen. Daneben fällt aber immer die gleiche Zusatzarbeit an: Verbindungen absichern, Fehler protokollieren, Messwerte sammeln. Ein Sidecar-Prozess ist ein zweites, kleines Programm, das genau diese Zusatzarbeit übernimmt. Es läuft direkt neben dem eigentlichen Programm auf derselben Maschine und teilt sich mit ihm Netzwerk und Speicher. Der Name kommt vom Beiwagen eines Motorrads: eine eigene Sitzeinheit, aber fest am Fahrzeug montiert und immer auf demselben Weg unterwegs.

Warum Firmen Zusatzarbeit auslagern

Ohne Sidecar müsste jedes einzelne Programm die Zusatzarbeit selbst erledigen. Bei zwanzig Programmen bedeutet das zwanzigmal denselben Code. Ändert sich eine Sicherheitsregel, muss ein Team zwanzig Programme anfassen und neu ausliefern. Mit einem Sidecar ändert man stattdessen nur den Beiwagen. Die eigentlichen Programme bleiben unangetastet.

Ein zweiter Vorteil ist die Unabhängigkeit von der Programmiersprache. In einer großen Firma ist ein Dienst in Java geschrieben, der nächste in Python, der dritte in Go. Ein Sidecar spricht mit ihnen nur über das Netzwerk. Deshalb funktioniert derselbe Beiwagen für alle drei, egal in welcher Sprache sie geschrieben sind.

Der Preis dafür ist Aufwand. Jeder Sidecar braucht Arbeitsspeicher und Rechenzeit, und bei tausend Diensten laufen tausend Beiwagen mit. Außerdem kostet jeder Umweg über das Sidecar ein paar Millisekunden. Firmen wägen deshalb ab, welche Aufgaben den Umweg wirklich wert sind.

Der Umweg über den Beiwagen

Technisch sitzt der Sidecar zwischen dem Hauptprogramm und der Außenwelt. Alles, was das Hauptprogramm nach draußen schickt, geht zuerst an den Sidecar. Der verschlüsselt die Daten, notiert den Vorgang und leitet ihn weiter. Eingehende Anfragen laufen denselben Weg rückwärts. Das Hauptprogramm merkt davon nichts, es glaubt, direkt mit dem Ziel zu sprechen.

Möglich wird das durch die gemeinsame Umgebung. Beide Prozesse laufen in derselben abgeschotteten Einheit, im System Kubernetes heißt sie Pod. Sie teilen sich dort die Netzwerkadresse und oft auch einen Ablageordner für Dateien. Ein Sidecar kann so zum Beispiel die Logdatei des Hauptprogramms mitlesen und deren Inhalt an einen zentralen Sammeldienst schicken.

Wichtig ist die Abgrenzung zu einer Bibliothek. Eine Bibliothek ist fertiger Code, den man in das eigene Programm einbaut, sie läuft also mit ihm im selben Prozess. Der Sidecar ist ein eigenständiger Prozess mit eigenem Speicher. Stürzt er ab, läuft das Hauptprogramm oft weiter, verliert aber seine Zusatzfunktionen. Ein häufiger Irrtum ist, Sidecars seien immer Container: das ist der übliche Fall, aber kein Muss.

Sidecars in Rechenzentren und KI-Diensten

Am bekanntesten ist das Muster in sogenannten Service Meshes, also Systemen, die den Datenverkehr zwischen vielen Diensten regeln. Bekannte Vertreter sind Istio und Linkerd. Sie stellen neben jeden Dienst einen Netzwerk-Sidecar, meist die Software Envoy. Der übernimmt Verschlüsselung, Lastverteilung und Wiederholungsversuche bei Fehlern.

Auch bei KI-Anwendungen taucht das Muster auf. Neben einem Modellserver läuft oft ein Sidecar, der jede Anfrage zählt und die Kosten dem richtigen Kunden zuordnet. Andere Sidecars prüfen Eingaben auf verbotene Inhalte, bevor sie das Modell erreichen. Man nennt solche Filter Guardrails.

In Fachnachrichten begegnet dir der Begriff derzeit vor allem in einer Debatte. Weil Sidecars viel Speicher verbrauchen, arbeiten Entwickler an sidecar-losen Alternativen, die dieselben Aufgaben tiefer im Betriebssystem erledigen. Wer die Diskussion verfolgt, sieht dort ein typisches Muster der Branche: Ein Konzept setzt sich durch, wird zum Standard und wird dann wegen seiner Kosten wieder infrage gestellt.