Microservices bezeichnen einen Architekturstil, bei dem eine Anwendung nicht als ein einziger, zusammenhängender Block (Monolith) gebaut wird, sondern als eine Sammlung vieler kleiner, fachlich klar abgegrenzter Dienste, die jeweils eigenständig entwickelt, getestet, deployt und skaliert werden. Jeder Dienst kümmert sich um eine abgegrenzte Geschäftsfähigkeit – im E-Commerce etwa Warenkorb, Katalog, Preisfindung, Checkout oder Versand – und kommuniziert mit den anderen über klar definierte Schnittstellen, in der Regel über das Netzwerk via HTTP/REST, gRPC oder asynchrone Nachrichten.
Microservices im Gegensatz zum Monolithen
Um Microservices zu verstehen, hilft der Blick auf das, was sie ablösen: den Monolithen. In einer monolithischen Anwendung leben Benutzeroberfläche, Geschäftslogik und Datenzugriff in einer einzigen Codebasis und einem einzigen Deployment-Artefakt. Das hat lange gut funktioniert und tut es in vielen Fällen bis heute – ein Monolith ist einfach zu entwickeln, einfach zu testen und einfach zu betreiben, solange das Team und die Domäne überschaubar bleiben.
Die Probleme beginnen mit der Größe. Wächst der Monolith, wachsen auch die Abhängigkeiten zwischen seinen Teilen. Eine kleine Änderung am Checkout kann ungewollt die Suche beeinflussen. Jeder Release betrifft das gesamte System, also muss alles gemeinsam getestet und ausgerollt werden. Skalieren lässt sich nur das Ganze, selbst wenn nur ein kleiner Teil unter Last steht. Microservices brechen diese Kopplung auf, indem sie die Anwendung entlang fachlicher Grenzen in unabhängige Einheiten zerlegen.
Kernmerkmale einer Microservice-Architektur
Nicht jede verteilte Anwendung ist automatisch eine Microservice-Architektur. Charakteristisch sind einige wiederkehrende Prinzipien:
- Fachlicher Schnitt (Bounded Context): Jeder Dienst kapselt eine Geschäftsfähigkeit, idealerweise nach den Prinzipien des Domain-Driven Design. Der Schnitt folgt der Fachlichkeit, nicht der Technik.
- Eigene Datenhaltung: Jeder Dienst besitzt seine eigene Datenbank oder zumindest sein eigenes Datenschema. Ein Dienst greift nie direkt auf die Datenbank eines anderen zu, sondern nur über dessen API. Das verhindert versteckte Kopplung über das Datenmodell.
- Unabhängiges Deployment: Ein Dienst kann ausgerollt werden, ohne dass die anderen mit deployt werden müssen. Das ist der vielleicht wichtigste praktische Vorteil.
- Dezentrale Verantwortung: Kleine, autonome Teams verantworten je einen oder wenige Dienste über den gesamten Lebenszyklus – „you build it, you run it“.
- Technologische Freiheit: Da Dienste nur über Schnittstellen kommunizieren, kann jedes Team intern die passende Sprache, Datenbank oder Bibliothek wählen. In der Praxis wird diese Freiheit aus Wartbarkeitsgründen meist bewusst eingeschränkt.
- Ausfalltoleranz by Design: Da Aufrufe über das Netz gehen, muss jeder Dienst damit rechnen, dass ein anderer nicht erreichbar ist. Patterns wie Timeouts, Retries, Circuit Breaker und Fallbacks gehören zum Handwerk.
Kommunikation zwischen Diensten
Dienste sprechen entweder synchron oder asynchron miteinander. Synchrone Kommunikation (z. B. ein REST- oder gRPC-Aufruf) ist einfach zu verstehen, koppelt die Dienste aber zeitlich: Der aufrufende Dienst wartet auf die Antwort und ist auf die Verfügbarkeit des aufgerufenen angewiesen. Asynchrone Kommunikation über Message Broker wie Apache Kafka oder RabbitMQ entkoppelt die Dienste: Ein Dienst veröffentlicht ein Ereignis („Bestellung aufgegeben“), andere reagieren darauf, ohne dass der Sender wissen muss, wer zuhört. Ereignisgetriebene Architekturen sind robuster gegen Ausfälle, dafür schwerer nachzuvollziehen und zu debuggen.
Warum Microservices im E-Commerce relevant sind
Gerade im Handel ist der Architekturstil eng mit dem Trend zu Composable und Headless Commerce verknüpft. Statt einer geschlossenen Suite, die Frontend, Katalog, Warenkorb, Checkout, Promotions und Suche in einem Paket liefert, setzen moderne Plattformen auf austauschbare, über APIs verbundene Bausteine. Jeder Baustein – die Suche, das Preis-Engine, das Loyalty-System – kann ein eigener Dienst oder ein eingekauftes SaaS sein.
Der Nutzen ist konkret: Zum Black Friday lässt sich der Checkout-Dienst hochskalieren, ohne die gesamte Plattform aufzublasen. Eine neue Zahlart wird im Payment-Dienst ausgerollt, ohne die Produktsuche zu riskieren. Ein Suchanbieter kann gegen einen besseren ausgetauscht werden, weil nur eine API-Grenze betroffen ist. Diese Flexibilität ist der Hauptgrund, warum große Händler den Schritt gehen.
Wichtig für Shopware-Händler: Shopware 6 ist im Kern kein reiner Microservice-Stack, sondern ein modularer Monolith mit umfangreicher API-Schicht (Store API und Admin API). Das erlaubt einen headless Betrieb und das Anbinden externer Dienste, ohne dass man die gesamte Plattform in Microservices zerlegen muss. In der Praxis ist genau dieser Mittelweg – ein solider Kern plus ausgewählte, ausgelagerte Dienste – für die meisten Händler sinnvoller als eine vollständige Microservice-Landschaft.
Ein konkretes Beispiel: Netflix
Das bekannteste reale Beispiel für Microservices in großem Maßstab ist Netflix. Das Unternehmen migrierte ab 2009 von einer monolithischen Anwendung auf eine Architektur aus mehreren hundert Diensten in der AWS-Cloud, nachdem ein Datenbankausfall den Versand tagelang lahmgelegt hatte. Netflix hat aus dieser Migration zahlreiche Open-Source-Werkzeuge hervorgebracht (etwa Hystrix für Circuit Breaking oder das „Chaos Monkey“-Tool, das im Betrieb gezielt Dienste abschießt, um die Ausfalltoleranz zu testen). Das Beispiel zeigt beides: den enormen Skalierungsgewinn und den Preis in Form von operativer Komplexität, die ein eigenes Spezialwissen erfordert.
Vorteile und Nachteile im Überblick
| Vorteile | Nachteile / Kosten |
|---|---|
| Unabhängiges Deployment einzelner Dienste | Hohe operative Komplexität (Monitoring, Logging, Tracing) |
| Gezielte Skalierung einzelner Komponenten | Verteilte Systeme sind schwer zu debuggen |
| Kleine, autonome Teams | Netzwerklatenz und Teilausfälle als Normalfall |
| Technologische Freiheit pro Dienst | Datenkonsistenz über Dienste hinweg wird komplex (eventual consistency) |
| Bessere Fehlerisolation | Mehr Infrastruktur- und DevOps-Aufwand |
Häufige Missverständnisse
Ein verbreiteter Irrtum ist, dass „mehr Dienste“ automatisch „besser“ bedeute. Zu fein geschnittene Dienste – manchmal abwertend „Nanoservices“ genannt – erzeugen mehr Netzwerk-Overhead und Koordinationsaufwand, als sie an Vorteilen bringen. Ein zweiter Irrtum: Microservices seien eine rein technische Entscheidung. Tatsächlich spiegelt die Architektur die Organisation wider (Conway's Law) – ohne entsprechend geschnittene, autonome Teams entsteht aus Microservices schnell ein „verteilter Monolith“, der die Nachteile beider Welten vereint. Viele erfahrene Architekten empfehlen daher den „Monolith First“-Ansatz: erst mit einem gut strukturierten Monolithen starten und nur dort herausschneiden, wo der Druck real wird.
Werkzeuge und Betrieb
Microservices werden heute fast immer in Containern (Docker) verpackt und über Orchestrierer wie Kubernetes betrieben. Dazu kommen Bausteine für Service Discovery, API-Gateways, zentrales Logging, Metriken (Prometheus/Grafana) und verteiltes Tracing (OpenTelemetry, Jaeger), um eine Anfrage über mehrere Dienste hinweg nachverfolgen zu können. Dieser „Betriebsapparat“ ist der eigentliche Aufwand: Wer Microservices einführt, investiert zwangsläufig in Plattform- und DevOps-Kompetenz.
Ausblick
Der Hype um Microservices der 2010er Jahre ist einer nüchterneren Sicht gewichen. Heute gilt die Faustregel, dass die Architektur zum Problem passen muss: Große Organisationen mit vielen Teams und hoher Skalierungslast profitieren klar, kleinere Projekte fahren mit einem gut strukturierten Modul-Monolithen oft günstiger und schneller. Parallel entstehen Zwischenformen wie „Self-Contained Systems“ und „Modular Monoliths“, die einen Teil der Vorteile ohne die volle operative Last bieten. Für den E-Commerce bleibt der entscheidende Hebel weniger die reine Anzahl der Dienste als die Fähigkeit, einzelne Fähigkeiten – Suche, Checkout, Payment – unabhängig weiterzuentwickeln und auszutauschen.
Eine ausführliche, herstellerneutrale Einordnung des Begriffs bietet etwa die grundlegende Definition von Martin Fowler und James Lewis, die den Stil maßgeblich geprägt hat.
FAQ
Was ist der Unterschied zwischen Microservices und einem Monolithen?
Ein Monolith ist eine einzige, zusammenhängende Anwendung mit einem Deployment. Eine Microservice-Architektur zerlegt dieselbe Funktionalität in viele kleine, unabhängig deploybare Dienste mit eigener Datenhaltung.
Brauchen kleine Online-Shops Microservices?
In der Regel nein. Für kleine und mittlere Shops überwiegen die Betriebskosten den Nutzen. Ein modularer Monolith mit guter API-Schicht – wie ihn Shopware 6 bietet – ist meist die wirtschaftlichere Wahl.
Sind Microservices dasselbe wie Headless Commerce?
Nein, aber sie sind verwandt. Headless trennt Frontend und Backend über APIs; Microservices zerlegen das Backend selbst in Dienste. Man kann headless arbeiten, ohne Microservices zu nutzen.
Welche Technologien gehören typischerweise dazu?
Container (Docker), Orchestrierung (Kubernetes), API-Gateways, Message Broker (Kafka, RabbitMQ) sowie Werkzeuge für Monitoring, Logging und verteiltes Tracing.