Microservices – Mikrodienste – bezeichnen einen Architekturstil, bei dem eine Anwendung als Sammlung kleiner, unabhängiger Services entwickelt und betrieben wird. Jeder Service übernimmt eine eng begrenzte, klar definierte Aufgabe, hat seinen eigenen Datenspeicher, läuft in einem eigenen Prozess und kommuniziert mit anderen Services ausschließlich über wohldefinierte, leichtgewichtige Schnittstellen – typischerweise REST APIs oder Message Queues.
Microservices sind die moderne Antwort auf die Einschränkungen monolithischer Architekturen: Durch die Zerteilung einer großen Anwendung in kleine, unabhängige Einheiten wird jeder Service einzeln entwickelbar, deploybar, skalierbar und ersetzbar. Das ermöglicht agile Entwicklung in größeren Teams, unabhängige Technologiewahl je Service und gezielte Skalierung der Teile, die unter Last stehen.
Kerncharakteristika von Microservices
Single Responsibility
Jeder Service tut genau eine Sache und tut sie gut – wie eine Funktion, nur als eigenständiger Prozess.
Unabhängiges Deployment
Jeder Service kann unabhängig aktualisiert werden – kein Stopp des Gesamtsystems für ein Update eines einzelnen Services.
Eigener Datenspeicher
Keine gemeinsam genutzte Datenbank – jeder Service verwaltet seine Daten selbst und gibt sie nur über seine API preis.
Technologiefreiheit
Jedes Team kann die für seinen Service beste Technologie wählen – kein Zwang zur einheitlichen Programmiersprache.
Fehlerisolation
Ein ausgefallener Service beeinträchtigt andere nicht – Circuit Breaker und Fallbacks sichern das Gesamtsystem ab.
Gezielte Skalierung
Nur der Service, der unter Last steht, wird skaliert – nicht die gesamte Anwendung.
Microservices und Automatisierung
Das Microservice-Prinzip ist direkt auf Automatisierungsarchitekturen übertragbar: Statt einem monolithischen Megaworkflow werden kleine, spezialisierte Teilworkflows entwickelt, die über definierte Schnittstellen (Webhooks, Message Queues, API-Calls) miteinander kommunizieren. Jeder Teilworkflow kann unabhängig weiterentwickelt, skaliert, getestet und deployed werden. Fehler in einem Teilworkflow isolieren sich, ohne andere zu beeinflussen.
Praxisbeispiel
Ein SaaS-Unternehmen migiert seinen Onboarding-Prozess vom Monolith zur Microservice-Architektur. Statt einem Workflow mit 60 Schritten entstehen 7 unabhängige Services: (1) Account-Provisioning, (2) E-Mail-Sequenz, (3) CRM-Datensynchronisation, (4) Billing-Setup, (5) Dokumentenbereitstellung, (6) Analysemessung, (7) Slack-Benachrichtigungen. Jeder Service kommuniziert über Events: „Account erstellt“ triggert alle anderen Services parallel. Wenn der Billing-Service vorübergehend ausfällt, laufen die anderen 6 Services weiter – Billing wird nachgeholt, wenn der Service wieder verfügbar ist. Deployment eines Updates am E-Mail-Service: ohne Stopp der anderen 6 Services, in 3 Minuten live.
