Was sind Microservices?

Microservices sind ein Architekturstil, bei dem eine Anwendung aus vielen kleinen, eigenständigen Diensten besteht. Jeder Dienst erfüllt eine klar umrissene fachliche Aufgabe, etwa Bestellungen, Rechnungen oder Benutzerkonten, hat oft seine eigene Datenhaltung und kommuniziert mit den anderen über Schnittstellen. Dadurch lassen sich Teile unabhängig entwickeln, ausrollen und skalieren.

Bekannt wurde das Prinzip durch große Plattformen wie Netflix oder Amazon, die mit Hunderten Teams an einem Produkt arbeiten. Für den Mittelstand stellt sich eine nüchternere Frage: Welche Vorteile kommen bei uns an, und welchen Aufwand holen wir uns ins Haus?

Was Microservices sind

Das Gegenstück ist der Monolith: eine Anwendung, in der alle Funktionen in einem Programm stecken und gemeinsam ausgeliefert werden. Bei Microservices wird dieses Programm entlang fachlicher Grenzen zerlegt. Typische Merkmale:

• Eine Aufgabe pro Dienst: Der Rechnungsdienst weiß alles über Rechnungen und nichts über Lagerplätze.
• Eigene Daten: Jeder Dienst verwaltet seine Daten selbst. Andere Dienste fragen über Schnittstellen, nicht direkt in fremden Tabellen.
• Unabhängige Auslieferung: Eine Änderung am Versanddienst geht live, ohne dass der Rest neu ausgeliefert wird.
• Technische Freiheit: Dienste können in unterschiedlichen Sprachen geschrieben sein, wenn es dafür einen Grund gibt.

Wie Microservices zusammenarbeiten

Die Dienste sprechen über das Netzwerk miteinander, meist auf zwei Arten:

1. Direkte Anfragen: Ein Dienst ruft einen anderen über eine REST-API oder GraphQL auf und wartet auf die Antwort. Einfach, aber beide müssen gleichzeitig erreichbar sein.
2. Ereignisse: Ein Dienst meldet „Bestellung eingegangen“ an einen Nachrichtenkanal. Lager, Rechnung und Versand reagieren darauf, jeder in seinem Tempo. Das entkoppelt die Dienste, macht Abläufe aber schwerer nachzuvollziehen.

Davor steht oft ein API-Gateway, das Anfragen von außen annimmt und an die richtigen Dienste verteilt. Betrieben werden die Dienste typischerweise in Containern, orchestriert von Plattformen wie Kubernetes.

Monolith oder Microservices?

Ein Mittelweg ist der modulare Monolith: eine Anwendung, intern sauber in Module mit klaren Grenzen geteilt. Er lässt sich später Stück für Stück aufteilen, wenn ein Teil tatsächlich eigene Wege braucht. Viele erfahrene Architekten empfehlen genau diesen Weg.

Beispiel: ein Onlineshop in Diensten

Ein Händler für Arbeitsschutzbekleidung betreibt Shop, Warenwirtschaftsanbindung und Händlerportal. In einer Microservice-Architektur könnten das folgende Dienste sein:

• Katalog: Artikel, Größen, Bilder – stark gelesen, selten geändert.
• Warenkorb und Bestellung: kritisch für den Umsatz, braucht hohe Verfügbarkeit.
• Preise: Staffelpreise und Händlerkonditionen aus dem ERP.
• Versand: Labels, Sendungsnummern, Rückmeldungen der Paketdienste.
• Benachrichtigungen: E-Mails und Statusmeldungen.

Der Nutzen: Fällt der Versanddienst eines Paketdienstleisters aus, können Kunden weiter bestellen. Im Weihnachtsgeschäft wird nur der Katalog stärker skaliert. Der Preis: fünf Dienste statt einer Anwendung, die überwacht, aktualisiert und gesichert werden müssen.

Was Microservices voraussetzen

• Automatisierte Auslieferung über CI/CD, sonst wird jede Änderung zur Handarbeit.
• Zentrale Überwachung mit Protokollen und Kennzahlen aller Dienste an einem Ort.
• Klare fachliche Grenzen, damit Dienste nicht ständig aufeinander warten.
• Betriebserfahrung im Team oder beim Dienstleister, Stichwort DevOps.

Fehlt eine dieser Voraussetzungen, kehren sich die Vorteile um. Ohne automatisierte Auslieferung wird die gewonnene Unabhängigkeit zur Mehrarbeit, ohne zentrale Überwachung sucht das Team bei einer Störung stundenlang, in welchem Dienst der Fehler steckt. Prüfen Sie deshalb vor einer Aufteilung ehrlich, ob Ihr Team oder Ihr Dienstleister diese Grundlagen heute schon beherrscht.

Fallstricke

Der häufigste Fehler ist der „verteilte Monolith“: Dienste, die so eng voneinander abhängen, dass sie doch nur gemeinsam funktionieren – mit allen Nachteilen beider Welten. Ein zweiter Fallstrick sind Daten, die über mehrere Dienste konsistent bleiben müssen. Was in einer Datenbank eine einfache Transaktion ist, wird verteilt zu einer kleinen Wissenschaft. Und schließlich die Kosten: Mehr Dienste bedeuten mehr Infrastruktur, mehr Überwachung und mehr Wissen, das im Team vorhanden sein muss. Wer Microservices nur einführt, weil sie modern klingen, zahlt diesen Preis ohne Gegenwert.

In der Praxis: so viel Aufteilung wie nötig

Bei Web-Anwendungen für den Mittelstand wählen wir die Architektur nach Teamgröße, Last und Änderungstempo, nicht nach Trend. Häufig ist das ein gut geschnittener Kern mit wenigen eigenständigen Diensten für Aufgaben, die wirklich getrennt laufen sollen, etwa Dokumentenverarbeitung oder Schnittstellen zu Partnern. Wer eine gewachsene Anwendung aufteilen will, findet bei der IT-Modernisierung einen schrittweisen Weg ohne Stillstand.

Häufige Fragen

Was sind Microservices einfach erklärt?

Statt eines großen Programms gibt es viele kleine, die jeweils eine Aufgabe erledigen und sich über Schnittstellen verständigen. Man kann sie einzeln ändern und ausliefern.

Sind Microservices immer besser als ein Monolith?

Nein. Für kleine und mittlere Teams ist ein gut strukturierter Monolith oft schneller, günstiger und leichter zu betreiben. Microservices lohnen sich bei vielen Teams, stark schwankender Last oder sehr unterschiedlichen Teilen.

Was ist der Unterschied zwischen Microservices und Middleware?

Microservices sind die Bausteine einer Anwendung. Middleware ist Software, die zwischen Anwendungen oder Diensten vermittelt, etwa Nachrichten weiterleitet oder Daten umwandelt.