Nanoservices

Große Programme bestehen heute selten aus einem einzigen Stück. Stattdessen zerlegt man sie in kleinere Teile, die getrennt laufen und sich über das Netzwerk Nachrichten schicken. Nanoservices sind der Extremfall dieser Zerlegung: Jedes Teil ist so klein, dass es oft nur eine einzelne Funktion erfüllt, etwa eine Postleitzahl prüfen oder ein Datum umrechnen. Der Begriff stammt aus der Softwareentwicklung und ist bewusst als Übertreibung gemeint. Fachleute benutzen ihn meistens als Warnung: Hier wurde zu fein geschnitten. Ein Nanoservice ist damit kein Fortschritt gegenüber einem etwas größeren Baustein, sondern ein Zeichen dafür, dass eine gute Idee zu weit getrieben wurde.

Wenn die Zerlegung teurer wird als der Nutzen

Software in eigenständige Teile zu zerlegen hat echte Vorteile. Ein Team kann seinen Teil ändern, ohne alle anderen zu stören. Fällt ein Teil aus, läuft der Rest oft weiter. Und stark genutzte Teile lassen sich einzeln verstärken, statt das ganze Programm größer zu machen. Genau deshalb sind solche Architekturen in den letzten Jahren zum Standard geworden.

Jeder eigenständige Teil verursacht aber auch feste Kosten. Er braucht eine eigene Startumgebung, eine Überwachung, Protokolle, eine Versionsverwaltung und eine Schnittstelle nach außen. Dieser Aufwand ist bei einem großen Baustein gerechtfertigt. Bei einem Baustein mit zwanzig Zeilen Code ist er absurd. Man verwaltet dann mehr Drumherum als eigentlichen Programmcode.

Dazu kommt ein Punkt, den man leicht unterschätzt: Jeder Aufruf über das Netzwerk dauert länger als ein Aufruf innerhalb desselben Programms. Ein direkter Funktionsaufruf braucht Bruchteile einer Millionstelsekunde. Ein Netzwerkaufruf liegt schnell bei mehreren Millisekunden. Wenn eine einzige Nutzeranfrage dreißig Nanoservices nacheinander befragt, summiert sich das zu spürbarer Wartezeit.

Was den Schnitt zu fein macht

Entscheidend ist nicht die Zeilenzahl, sondern die Frage, ob ein Baustein für sich allein sinnvoll ist. Ein guter Baustein besitzt eigene Daten und kann eine fachliche Aufgabe vollständig erledigen, etwa die Bestellungen eines Shops verwalten. Ein Nanoservice dagegen kann nichts allein. Er braucht bei fast jedem Aufruf Informationen von anderen Teilen.

Daraus entsteht das Hauptproblem: Änderungen bleiben nicht lokal. Wer ein Feld hinzufügt, muss plötzlich sechs Bausteine gleichzeitig anpassen und in der richtigen Reihenfolge neu ausrollen. Die Teile sind zwar technisch getrennt, hängen fachlich aber eng zusammen. Fachleute nennen das einen verteilten Monolithen: Man hat alle Nachteile eines großen Programms und zusätzlich die Nachteile eines Netzwerks.

Ein Vergleich macht das greifbar. Eine Küche in Arbeitsbereiche zu teilen ist sinnvoll: Vorspeisen, Hauptgerichte, Nachtisch. Jeder Bereich hat eigene Zutaten und liefert ein fertiges Ergebnis. Würde man stattdessen je eine Person nur fürs Salzen, eine nur fürs Rühren und eine nur fürs Abschmecken abstellen, müsste ständig jemand rufen, warten und weiterreichen. Genau so verhalten sich Nanoservices.

Wo der Vorwurf in der Praxis auftaucht

Am häufigsten begegnet dir der Begriff in Diskussionen unter Entwicklern, etwa in Blogbeiträgen oder Vorträgen über gescheiterte Umbauten. Typisch ist die Geschichte einer Firma, die ihre Anwendung in hunderte Teile zerlegt hat und danach einen Teil davon wieder zusammenführte. Solche Rückbauten werden offen dokumentiert und sind ein wiederkehrendes Thema auf Technikkonferenzen.

Eine Sonderrolle spielen Cloud-Angebote, bei denen man nur einzelne kleine Funktionen hochlädt und pro Aufruf bezahlt. Dort sind winzige Bausteine technisch gewollt, weil der Anbieter die Verwaltung übernimmt. Trotzdem gilt auch hier: Wer fachlich Zusammengehöriges auf zu viele Funktionen verteilt, bekommt dieselben Probleme mit Abstimmung und Wartezeit.

Für dich als Leser von Technik-Nachrichten ist vor allem die Abgrenzung nützlich. Bausteine mittlerer Größe gelten als bewährte Praxis. Nanoservices sind kein eigener Architekturstil, den jemand bewusst anstrebt, sondern eine Diagnose. Wenn in einem Artikel steht, ein System sei in Nanoservices zerfallen, bedeutet das: Es wurde zu klein geschnitten und ist dadurch schwerer zu betreiben geworden.