Was sind Microservices?
Microservices zerlegen eine Anwendung in kleine, unabhängig deploybare Dienste, die jeweils eine klar abgegrenzte Aufgabe erfüllen. Jeder Service kann von einem eigenen Team entwickelt, in einer eigenen Sprache geschrieben und unabhängig skaliert werden. Der Preis dafür ist mehr Komplexität bei Kommunikation und Monitoring.
Auch bekannt als: Microservice-Architektur · Mikroservices · Verteilte Dienste
Ist Microservices bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Jeder Microservice ist ein eigener Prozess mit eigenem Repository, eigener Pipeline und meist eigener Datenbank. Die Dienste rufen sich über das Netzwerk auf, synchron per HTTP-API oder gRPC, einem binären Protokoll für entfernte Funktionsaufrufe. Alternativ tauschen sie Ereignisse über einen Message Broker aus, etwa Kafka oder einen MQTT-Broker. Kein Dienst greift direkt auf die Datenbank eines anderen zu. Ändert ein Team seinen Dienst, baut und deployt es nur diesen einen, solange die Schnittstelle stabil bleibt.
Der eigentliche Nutzen ist organisatorisch. Teams releasen in ihrem eigenen Tempo, ohne auf andere zu warten, und skalieren einen einzelnen Dienst statt der ganzen Anwendung. Jeder Service kann in der Sprache geschrieben sein, die für seine Aufgabe passt. Spürbar wird das allerdings erst, wenn mehrere Teams an einem System arbeiten.
Der Preis ist verteilte Komplexität. Was im Monolithen ein Methodenaufruf war, wird zum Netzwerkaufruf mit Latenz, Ausfallrisiko und der Frage, wie Daten über Service-Grenzen hinweg konsistent bleiben. Monitoring, verteiltes Tracing, Service-Discovery und eine Orchestrierung, typischerweise über Kubernetes, werden Pflicht. Wer Microservices ohne reife CI/CD- und Observability-Praxis einführt, tauscht eine handhabbare Komplexität gegen eine schwer beherrschbare.
Für Industrieunternehmen gilt besondere Vorsicht, denn oft ist ein gut strukturierter Monolith die wirtschaftlichere Wahl. Wer aufteilt, sollte das entlang fachlicher Domänen tun statt nach technischen Schichten. Ein zu fein oder technisch geschnittenes System wird zum verteilten Monolithen, der die Nachteile beider Architekturen vereint. Wir haben Teams gesehen, die zwei Jahre in den Umbau investierten und deren Releases danach länger dauerten als im alten Monolithen, weil jede Änderung drei Dienste gleichzeitig betraf.
Ingest-Service skaliert, Report-Service bleibt klein
In einer Plattform für Produktionsdaten musste bisher die ganze Anwendung für die Lastspitzen der Datenaufnahme dimensioniert werden. Nach der Aufteilung verarbeitet ein Ingest-Service die Sensordaten und skaliert mit der Last, während ein Report-Service nur gelegentlich läuft. Die Rechenkapazität folgt jetzt dem Dienst, der sie tatsächlich braucht.
Altsystem Domäne für Domäne abgelöst
Ein gewachsenes Altsystem sollte ersetzt werden, ein Big-Bang-Wechsel war für den laufenden Betrieb zu riskant. Das Team lagerte stattdessen eine fachliche Domäne nach der anderen in eigene Dienste aus. Der Monolith schrumpft kontrolliert, während die neuen Services bereits produktiv laufen.
Sind Microservices der richtige Schnitt für Sie?
Microservices lösen echte Skalierungsprobleme — schaffen aber auch neue. Ob sie sich lohnen, hängt an Ihrem Schmerz. Zwei Klicks ordnen ein.
Wo stehen Sie heute?
- Sind Microservices immer besser als ein Monolith?
- Nein. Microservices lohnen sich erst ab einer gewissen Team- und Systemgröße, weil sie verteilte Komplexität einführen. Ein gut strukturierter modularer Monolith ist für viele Anwendungen wirtschaftlicher und einfacher zu betreiben.
- Wie schneide ich Microservices sinnvoll zu?
- Der Schnitt sollte sich an fachlichen Domänen orientieren, nicht an technischen Schichten. Ein Service kapselt idealerweise eine abgeschlossene Geschäftsfähigkeit samt eigener Datenhaltung. Dann bleiben Änderungen lokal, und Teams müssen sich nicht bei jedem Release über Service-Grenzen hinweg abstimmen.
- Was ist ein verteilter Monolith?
- Ein verteilter Monolith entsteht, wenn Microservices so eng gekoppelt sind, dass sie nur gemeinsam deployt und geändert werden können. Das System hat dann die Komplexität verteilter Systeme, aber nicht deren Unabhängigkeit. Meist ist ein zu feiner oder falsch gewählter Schnitt die Ursache.
Wo steht Ihr Team bei Microservices?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Microservices: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Martin Fowler und James LewisMicroservices(externe Seite, öffnet in neuem Tab)
Der Artikel, der die Merkmale des Architekturstils zuerst zusammengefasst hat.
- /02microservices.ioMicroservice Architecture Pattern(externe Seite, öffnet in neuem Tab)
Mustersammlung von Chris Richardson mit Vor- und Nachteilen je Entscheidung.
- /03Microsoft LearnMicroservices-Architekturstil(externe Seite, öffnet in neuem Tab)
Einordnung mit Betriebsaufwand, Datenhaltung und typischen Fallstricken.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance