Composability (Komponierbarkeit)

Was ist Composability?

Composability (auf Deutsch Komponierbarkeit) ist ein Entwurfsprinzip: Ein System besteht aus eigenständigen Komponenten, die sich auswählen, kombinieren, austauschen und neu zusammensetzen lassen. In einem composable System ersetzen Sie einen Teil, etwa einen Suchdienst oder einen Zahlungsanbieter, ohne den Rest neu zu bauen. Darauf beruhen die Composable Architecture und, weiter gefasst, das Composable Business.

So funktioniert Composability

Ein Teil ist composable, wenn er einige Bedingungen erfüllt:

• Eigenständig: Er lässt sich einzeln bereitstellen und ändern.
• Klare Schnittstelle: Er spricht über einen dokumentierten Vertrag mit anderen Teilen, meist eine API.
• Austauschbare Abhängigkeiten: Die Teile, auf die er sich stützt, lassen sich durch andere ersetzen, die denselben Vertrag einhalten.
• Oft zustandslos: Jede Anfrage wird für sich bearbeitet. Das ist eine Technik, keine Pflicht.

Composability ist eine Eigenschaft, kein Produkt. Ein System ist mehr oder weniger composable, je nachdem, wie frei sich seine Teile neu kombinieren lassen.

Drei Bedeutungen des Begriffs

• Composable Architecture: ein Technologie-Stack aus unabhängigen Diensten. Diese Bedeutung gilt auf dieser Seite und in den meisten Business-Texten. Sie baut auf Microservices und einem API-First-Ansatz auf. Das Kürzel MACH (Microservices, API-first, Cloud-native SaaS, Headless) steht oft für diesen Stil.
• UI-Komposition: Oberflächen, die aus kleinen, wiederverwendbaren Komponenten entstehen. Ein Micro Frontend wendet dieselbe Idee auf ganze Bereiche einer Oberfläche an.
• Funktionskomposition: Programmierung, bei der das Ergebnis einer Funktion zur Eingabe der nächsten wird.

Beispiel: ein composable Onlineshop

Ein Shop nutzt ein Headless-CMS für Inhalte, einen eigenen Suchdienst, einen Checkout-Dienst und einen Zahlungsanbieter. Jeder stellt eine API bereit, und ein schlankes Frontend setzt sie zusammen. Wird der Suchdienst zu langsam oder zu teuer, ersetzt das Team ihn durch einen anderen mit ähnlicher API und ändert nur die Anbindung. CMS, Checkout und Zahlungen laufen unverändert weiter.

Vorteile und Nachteile

• Flexibilität: Einen Teil austauschen oder aktualisieren, ohne alles neu zu bauen.
• Unabhängige Skalierung und Verantwortung: Teams veröffentlichen ihre Teile im eigenen Rhythmus.
• Mehr Integrationsarbeit: Jede Verbindung muss gebaut, abgesichert und kompatibel gehalten werden.
• Mehr mögliche Ausfallstellen: Eine langsame Abhängigkeit kann die ganze Strecke bremsen.

Häufige Fehler

• Zu feine Aufteilung. Dutzende winziger Teile vervielfachen Verbindungen und Abstimmung. Teilen Sie dort, wo sich Änderung oder Last wirklich unterscheiden.
• Vage Verträge. Ohne dokumentierte, versionierte Schnittstellen bricht eine Änderung in einem Teil einen anderen. Wie man erweitert, ohne Aufrufer zu brechen, steht unter Erweiterbarkeit.
• Unklare Zuständigkeit. Jeder Teil braucht ein verantwortliches Team, auch für Verfügbarkeit und Updates.
• Anbieter-Wildwuchs. Für alles das beste Einzelwerkzeug zu kaufen ergibt viele Rechnungen, Logins und Supportkanäle.
• Teile nur einzeln testen. Jeder Teil kann seine Tests bestehen, während die zusammengesetzte Strecke langsam oder kaputt ist.

Composability, Tests und Monitoring

Komposition fügt Netzwerkaufrufe hinzu, und jeder bringt Verzögerung und ein Ausfallrisiko mit. Überwachen Sie jede API einzeln mit API-Monitoring: LoadFocus API-Monitoring kann Anfragen zu mehrstufigen Abläufen verketten, sodass Sie eine ganze Strecke wie Login, Suche und Checkout prüfen, und der kostenlose Plan prüft alle 5 Minuten. Führen Sie vor einem Launch oder einer Aktion einen Lasttest gegen die zusammengesetzte Strecke durch, nicht nur gegen einzelne Dienste. Der Leitfaden zum Lasttest von Microservices in der Cloud beschreibt das Vorgehen.

Häufige Fragen: Composability

Was ist der Unterschied zwischen composable und modular?

Modular heißt, ein System ist in Teile gegliedert. Composable geht weiter: Die Teile sind mit klaren Schnittstellen so unabhängig, dass Sie sie frei neu kombinieren oder ersetzen können.

Ist Composability dasselbe wie Microservices?

Nein. Microservices sind eine Möglichkeit, eigenständige Teile zu bauen. Composability ist das Ziel, und Sie können es mit Diensten, Paketen, Komponenten oder SaaS-Produkten verfolgen.

Was ist Composable Architecture?

Eine Art, Software zu bauen, bei der der Stack aus unabhängigen, austauschbaren Diensten besteht, die über APIs verbunden sind, statt aus einer All-in-one-Plattform.

Wofür steht MACH?

Für Microservices, API-first, Cloud-native SaaS und Headless. Es ist eine Reihe von Prinzipien, mit denen oft composable Stacks beschrieben werden.

Ist ein composable System immer besser als ein Monolith?

Nein. Ein kleines Team mit einfachen Anforderungen ist mit einem integrierten System oft schneller. Composability lohnt sich, wenn sich Teile unterschiedlich schnell ändern oder skalieren.