Hub and Spoke:

Die unterschätzte Alternative zwischen Monolith und Microservices

In der Welt der Softwarearchitektur wird der Monolith oft als veraltetes Übel dargestellt, während Microservices als die moderne Lösung aller Probleme gefeiert werden. Doch zwischen diesen Extremen existiert ein Ansatz, der die Vorteile beider Welten geschickt vereint: Hub-and-Spoke-Architektur.

Vergleich auf einen Blick

Kriterium	Monolith	Microservices	Hub and Spoke
Komplexität	Gering am Anfang, hoch bei Wachstum	Hoch von Anfang an	Mittel, wächst kontrolliert
Deployment	Alles oder nichts	Unabhängig, aber aufwendig	Hub und Spokes können getrennt deployt werden
Skalierbarkeit	Grob (nur gesamte App)	Fein granular	Zielgerichtet (zentral + dezentral)
Technologie-vielfalt	Gering	Hoch	Mittel: Spokes flexibel, Hub stabil
Entwicklungs-geschwindigkeit	Schnell am Anfang, langsam später	Schwankend, abhängig von Organisation	Stabil und voraussagbar
Fehler-anfälligkeit	Fehler betreffen gesamtes System	Fehler können isoliert sein	Fehler im Hub kritisch, aber Spokes abgeschottet

Was ist Hub and Spoke?

Stell dir ein Rad vor: In der Mitte befindet sich die Nabe (Hub), von der Speichen (Spokes) zu den Außenbereichen führen. Übertragen auf die Softwarearchitektur bedeutet das:

Hub: Ein zentrales System (oft eine zentrale Plattform), das alle Kernlogik oder zentrale Geschäftsregeln bereitstellt.
Spokes: Leichte, spezialisierte Anwendungen oder Services, die mit dem Hub interagieren und jeweils eine klar umrissene Aufgabe erfüllen.

Wichtig dabei: Hub and Spoke ist nicht einfach ein halber Monolith oder lose Microservices – es ist ein bewusstes, organisiertes Mittelding.

Warum Monolithen oft problematisch sind

Monolithische Architekturen bündeln alle Funktionalitäten in einem einzigen Code- und Deployment-Block. Vorteile wie einfache Entwicklungsumgebung und direkte Kommunikation zwischen Komponenten schlagen bei wachsender Komplexität schnell in Nachteile um:

Technologischer Stillstand: Eine Änderung der Technologie (z.B. von einem alten Framework zu etwas Modernem) wird nahezu unmöglich.

Schwerfällige Deployments: Kleinste Änderungen verlangen umfangreiche Tests und Veröffentlichungen.

Skalierungsprobleme: Man skaliert immer die gesamte Anwendung, nie einzelne Teile.

Warum Microservices auch nicht immer die Antwort sind

Microservices haben eine starke Anziehungskraft: kleine, unabhängige Services, die unabhängig deploybar sind und in unterschiedlichen Technologien gebaut werden können. Aber:

Komplexität bei der Orchestrierung: Dutzende oder Hunderte Services müssen miteinander reden – das ist nicht trivial.
Verteilte Transaktionen: Konsistenz über Services hinweg wird schwer.
Overhead: Jedes Team braucht DevOps, Monitoring, Logging, API-Management – der Overhead vervielfacht sich.

Gerade kleine und mittlere Unternehmen geraten oft an ihre Grenzen, wenn sie versuchen, „wie Netflix“ Microservices zu bauen.

Hub and Spoke: Der goldene Mittelweg

Hier glänzt die Hub-and-Spoke-Architektur:

Sanfte Migration: Monolithische Altanwendungen können Stück für Stück in Spokes ausgegliedert werden, während der Hub Schritt für Schritt modernisiert wird.

Zentrale Steuerung: Der Hub verwaltet die Kerngeschäftslogik und stellt APIs bereit. Dadurch bleibt die Konsistenz gewahrt.

Flexibilität an den Rändern: Die Spokes können Technologien, Teams oder Releases schneller wechseln, ohne das gesamte System zu gefährden.

Weniger Orchestrierungsaufwand: Statt 100 gleichberechtigter Microservices kommunizieren die Spokes hauptsächlich mit dem Hub – das System bleibt übersichtlich.

Gezielte Skalierung: Der Hub kann separat skaliert werden (z.B. mehr Instanzen für Bestellverarbeitung), während einzelne Spokes ebenfalls angepasst werden können.

Wann lohnt sich Hub and Spoke?

Hub and Spoke ist ideal für Organisationen, die:

Komplexität managen müssen, ohne sich in 100 Services zu verzetteln,
bestehende Systeme modernisieren wollen, ohne einen „Big Bang“ zu riskieren,
Teams aufbauen, die schrittweise eigenständiger werden,
gleichzeitig Stabilität im Kern und Innovation an den Rändern brauchen.

Beispiele aus der Praxis sind etwa Plattformen, die zentrale Funktionen (Nutzerverwaltung, Authentifizierung, Payment) als Hub betreiben und spezialisierte Apps (z.B. Webshops, Mobile Apps) als Spokes andocken lassen.

Fazit

Hub and Spoke bietet eine ausgewogene Architektur, die viele Schwächen reiner Monolithen und reiner Microservices umgeht. Es erlaubt Unternehmen, systematisch und pragmatisch zu wachsen – ohne Komplexität zu früh aufzublähen oder Agilität durch ein schwerfälliges Monstrum zu verlieren.

In der Architekturdebatte sollte man öfter daran denken: Nicht alles, was glänzt, ist ein Microservice. Manchmal liegt die Zukunft in der Mitte.