Microservices

Microservices sind ein Architekturansatz, bei dem eine Anwendung aus vielen kleinen, unabhängigen Services besteht. Jeder Service erfüllt eine klar abgegrenzte Aufgabe. Services können unabhängig entwickelt, deployed und skaliert werden.

Ein Monolith ist eine große, zusammenhängende Anwendung. Microservices sind in viele kleine Services aufgeteilt. Microservices bieten mehr Flexibilität, sind aber komplexer.

Unabhängige Deployments sind möglich. Teams können autonom arbeiten. Skalierung erfolgt gezielt pro Service.

Höhere Komplexität durch verteilte Systeme. Netzwerkkommunikation kann fehleranfällig sein. Monitoring und Debugging sind schwieriger.

Bei großen, wachsenden Systemen. Wenn mehrere Teams parallel arbeiten. Bei Bedarf nach unabhängiger Skalierung.

Bei kleinen Anwendungen. Wenn das Team wenig Erfahrung hat. Der Overhead kann zu hoch sein.

Services sollten fachlich geschnitten sein. Domain-Driven Design hilft dabei. Zu feine Schnitte verursachen Probleme.

DDD hilft bei der Service-Aufteilung. Bounded Contexts definieren Grenzen. Jeder Service besitzt seine eigene Domäne.

Jeder Service verwaltet seine eigene Datenbank. Direkter Zugriff zwischen Services ist verboten. Konsistenz wird über Events erreicht.

Über synchrone APIs oder asynchrone Events. REST, gRPC oder Messaging werden genutzt. Asynchronität erhöht Entkopplung.

Services warten auf eine Antwort. REST ist ein typisches Beispiel. Latenzen können sich aufschaukeln.

Services kommunizieren über Events. Sender wartet nicht auf Antwort. Systeme sind robuster.

Events repräsentieren Zustandsänderungen. Andere Services reagieren darauf. Lose Kopplung wird erreicht.

Ein API Gateway ist ein zentraler Einstiegspunkt. Es übernimmt Routing und Security. Clients werden vereinfacht.

Services finden sich dynamisch. Registry-Systeme werden genutzt. Hardcodierte URLs werden vermieden.

Circuit Breaker verhindert Kettenausfälle. Fehlerhafte Services werden isoliert. Systeme bleiben stabil.

Bulkhead isoliert Ressourcen. Fehler bleiben lokal. Stabilität wird erhöht.

Saga steuert verteilte Transaktionen. Schritte werden kompensiert. Konsistenz wird eventual erreicht.

Tracing verfolgt Requests über Services hinweg. Tools wie Jaeger werden genutzt. Fehlerursachen werden sichtbar.

Observability umfasst Logs, Metriken und Traces. Systeme werden transparent. Fehler lassen sich besser analysieren.

Konfiguration wird zentral verwaltet. Änderungen erfolgen ohne Re-Deploy. Konsistenz wird sichergestellt.

Security ist dezentral und komplex. Authentifizierung erfolgt zentral. Autorisierung pro Service.

OAuth2 wird für Authentifizierung genutzt. Tokens werden zwischen Services weitergegeben. Zentrale Identity Provider sind üblich.

Kein Service vertraut implizit. Jeder Request wird geprüft. Sicherheit wird erhöht.

Services werden unabhängig skaliert. Last wird gezielt verteilt. Kosten werden optimiert.

Zwei Versionen laufen parallel. Umschalten erfolgt ohne Downtime. Risiko wird minimiert.

Neue Version wird schrittweise ausgerollt. Nur wenige Nutzer sehen sie. Fehler werden früh erkannt.

Zu viele Services. Falsche Service-Grenzen. Fehlendes Monitoring.

Unit- und Integrationstests sind wichtig. Contract Tests sichern APIs. End-to-End-Tests ergänzen.

Bei klarer Architektur. Mit guter Automatisierung. Und erfahrenen Teams.