Die beste Architektur entfernt Komponenten

Man verbindet gute Architektur mit dem Bild von etwas Errichtetem — mehr Bausteine, mehr Struktur, mehr Vorkehrung. Diese Geschichte erzählt vom Gegenteil: von einer Architektur, deren Wert im Weniger lag. Sie ist bewusst allgemein gehalten — ohne System, ohne Beteiligte, ohne Zeitpunkt.

Situation

Zwischen einem System und den Diensten, mit denen es sprach, standen Hunderte zwischengeschaltete API-Server — für jede Verbindung, jeden Zweck ein eigener. Jeder tat für sich wenig Auffälliges; zusammen bildeten sie eine ausgedehnte, schwer überschaubare Landschaft, die betrieben, überwacht und am Leben gehalten werden musste.

Ausgangsannahmen

Diese Landschaft war nicht durch eine Entscheidung entstanden, sondern durch viele kleine, je für sich naheliegende: Für jeden neuen Bedarf ein weiterer zwischengeschalteter Server, weil das im Moment der einfachste Weg war. Die stille Annahme war, dass jeder Zweck sein eigenes Stück Infrastruktur verdient — dass mehr Verbindungen mehr Server bedeuten.

Problem

Mit der Zahl der Komponenten wuchs nicht die Fähigkeit, sondern die Last, sie zu betreiben. Hunderte gleichartige Server sind Hunderte Orte, an denen etwas ausfallen, veralten, überwacht und aktualisiert werden muss. Die Infrastruktur trug kaum mehr Fähigkeit als eine schlanke, aber ein Vielfaches an Aufwand und Angriffsfläche. Die Komplexität lag nicht in dem, was das System konnte, sondern in dem, woraus es bestand.

Ursache

Die Ursache war, dass viele gleichartige Zwischenstücke sich zu einem Muster wiederholten, das man einmal hätte fassen können, aber nie gefasst hatte. Was Hunderte Server einzeln taten, war im Kern dieselbe Aufgabe — Anfragen entgegennehmen, weiterleiten, übersetzen. Diese Gleichartigkeit war die eigentliche Struktur; sie lag offen, aber niemand hatte sie als eine Sache behandelt, sondern als Hunderte.

Entscheidung

Die Entscheidung war, die vielen gleichartigen Komponenten durch eine einzige zu ersetzen, die ihre gemeinsame Aufgabe an einem Ort erfüllt — eine Proxy-Architektur. Nicht etwas hinzufügen, sondern das Wiederholte zusammenfassen und den Rest entfernen. Der Fortschritt bestand darin, dass am Ende weniger da war.

Umsetzung

Die gemeinsame Aufgabe der vielen Zwischenstücke wurde herausgeschält und an einer Stelle ausgedrückt — einem Proxy, der leistet, was zuvor über Hunderte Server verstreut war. Nach und nach wurden die einzelnen Server abgelöst und entfernt, jeder erst, wenn der Proxy seine Aufgabe belegt übernommen hatte. Am Ende stand eine deutlich einfachere Infrastruktur: weniger Komponenten, weniger Orte des Versagens, weniger, das man im Kopf behalten muss.

Trade-offs

Das Zusammenfassen hat einen Preis: Der eine Proxy wird wichtig — er trägt nun, was vorher verteilt war, und muss entsprechend robust und beobachtbar sein. Man tauscht viele kleine Ausfallstellen gegen eine bedeutende ein. Das ist ein guter Tausch, solange die eine Stelle sorgfältig gebaut ist; er wäre ein schlechter, wenn sie es nicht wäre. Anders würden wir entscheiden, wenn die Zwischenstücke wirklich verschieden wären — dann fasst man Ungleiches zusammen und erzwingt eine Einheit, die es nicht gibt.

Was wir gelernt haben

Die beste Architektur entfernt oft Komponenten, statt neue hinzuzufügen. Fähigkeit und Anzahl sind nicht dasselbe: Ein System aus vielen gleichartigen Teilen ist nicht mächtiger als eines, das dieselbe Aufgabe an einem Ort löst — nur teurer im Betrieb. Wo sich etwas vielfach wiederholt, liegt fast immer eine Struktur, die man einmal fassen kann. Die verlockende Frage lautet, welche Komponente man hinzufügt; die wertvollere, welche Wiederholung man auflöst.

Wie das Batunet verändert hat

Seither sehen wir eine wachsende Zahl gleichartiger Komponenten als Signal, nicht als Normalzustand — als Hinweis auf eine Struktur, die noch nicht gefasst ist. Wir fragen bei Infrastruktur zuerst, was sich zusammenfassen und entfernen lässt, bevor wir etwas ergänzen. Die einfachste Architektur, die die Aufgabe trägt, ist bei uns das Ziel, nicht die reichhaltigste.

Weiterführend

• Story: Komplexität entfernen statt hinzufügen — dieselbe Lektion, angewandt auf die Architektur einer Anwendung statt auf Infrastruktur.
• Guide: Modularer Monolith vs. Microservices — warum mehr Komponenten nicht mehr Fähigkeit bedeuten.
• Guide: API Design für langlebige Systeme — eine gemeinsame Aufgabe sauber an einer Stelle ausdrücken.
• Guide: Software, die in zehn Jahren noch läuft — warum weniger Teile ein System langlebiger machen.

Grundlage ist die Batunet Engineering Method: Wiederholung als Struktur erkennen, zusammenfassen statt vervielfachen, die einfachste tragfähige Architektur wählen.

Mehr Komponenten sind nicht mehr Architektur. Oft ist der beste Entwurf der, nach dem weniger dasteht — und das Wenige das Ganze trägt.