Microservices

Entstehung und Beteiligte

Die Architektur entstand aus serviceorientierten Systemen, Domain-Driven Design und Continuous Delivery. Der Begriff Microservices wurde um 2011 bei Softwarearchitektur-Workshops verwendet; Martin Fowler und James Lewis beschrieben 2014 die gemeinsamen Merkmale.

Welches Problem sollte gelöst werden?

Große monolithische Anwendungen wurden schwer unabhängig zu ändern und zu skalieren. Kleine, fachlich abgegrenzte Dienste sollten von autonomen Teams getrennt entwickelt und ausgeliefert werden können.

Technische Hürden und Lösungen

Verteilte Systeme bringen Netzfehler, Latenz, inkonsistente Daten, Versionsprobleme und aufwendige Beobachtung. Transaktionen über Dienste hinweg benötigen andere Muster. Zu kleine Dienste erzeugen mehr Betriebsaufwand als Nutzen.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• Der Begriff verbreitet sich ab etwa 2011.
• Jeder Dienst sollte einen klaren fachlichen Verantwortungsbereich besitzen.
• Datenhoheit pro Dienst reduziert Kopplung, erschwert aber Abfragen.
• Microservices sind eine Organisations- und Architekturentscheidung, kein Produkt.

Was sind Microservices?

Microservices-Architektur zerlegt eine Anwendung in kleine, unabhängig entwickelbare und deploybare Services. Jeder Service hat eine klar definierte Verantwortlichkeit (Single Responsibility), eine eigene Datenbank und kommuniziert über APIs oder Message-Queues mit anderen Services.

Gegenteil: Der Monolith – eine große Applikation, in der alle Module zusammen laufen und deployed werden. Monolithe sind für kleine Teams gut; bei Wachstum entstehen Skalierbarkeits- und Deployment-Probleme.

Vorteile und Herausforderungen

• Vorteile: Unabhängiges Deployment (kein Big Bang Release), unabhängige Skalierung (nur Payment hochskalieren), Technologie-Freiheit pro Service, Fehlertoleranz (ein Service fällt aus, andere laufen weiter), kleinere, überschaubare Code-Basen.
• Herausforderungen: Verteilte Systeme sind komplex – Netzwerklatenz, Teilausfälle, Datenkonsistenz über Services. Debugging und Tracing schwieriger. Mehr Betriebsaufwand (viele Services = viele Deployments, Monitoring, Logs).
• Kommunikation: Synchron (REST, gRPC) für direkte Requests. Asynchron (Kafka, RabbitMQ) für Events – entkoppelter und resilienter.

Patterns und Werkzeuge

Wichtige Patterns: API Gateway (einheitlicher Einstiegspunkt, Authentifizierung, Rate-Limiting), Circuit Breaker (verhindert Kaskadenfehler), Saga-Pattern (verteilte Transaktionen), Event Sourcing, CQRS.

Service Mesh (Istio, Linkerd) übernimmt: mTLS zwischen Services, Retries, Load Balancing, Tracing ohne App-Code. Distributed Tracing (Jaeger, Zipkin) korreliert Requests über Service-Grenzen hinweg.