Microservices (auch Microservices-Architektur) sind ein Softwarearchitektur-Ansatz, bei dem eine Anwendung als Sammlung kleiner, unabhaengiger Services aufgebaut wird. Jeder Service ist fuer genau eine Geschaeftsfunktion zustaendig, laeuft in einem eigenen Prozess und kommuniziert mit anderen Services ueber definierte APIs.
Die Microservices-Architektur ist das Gegenstueck zum Monolithen. Waehrend ein Monolith alle Funktionen in einer einzigen Anwendung buendelt, verteilt die Microservices-Architektur sie auf unabhaengige Einheiten. Netflix, Amazon, Spotify und Uber sind prominente Beispiele fuer Unternehmen, die erfolgreich auf Microservices setzen.
Grundprinzipien von Microservices
Single Responsibility
Jeder Microservice hat eine klar definierte Verantwortlichkeit:
- User Service: Nutzerverwaltung und Authentifizierung
- Product Service: Produktkatalog und -verwaltung
- Order Service: Bestellabwicklung
- Payment Service: Zahlungsverarbeitung
- Notification Service: E-Mails, Push-Benachrichtigungen
Unabhaengige Deployments
Jeder Service kann unabhaengig deployed werden. Ein Update am Payment Service erfordert kein Redeployment der gesamten Anwendung. Das beschleunigt Release-Zyklen erheblich.
Eigene Datenhaltung
Jeder Service besitzt seine eigene Datenbank. Der User Service speichert Nutzerdaten in PostgreSQL, der Product Service verwendet MongoDB, der Search Service nutzt Elasticsearch. Diese Autonomie verhindert enge Kopplung.
Microservices vs. Monolith
| Kriterium | Monolith | Microservices |
|---|---|---|
| Deployment | Gesamte Anwendung | Einzelne Services |
| Skalierung | Gesamte Anwendung | Pro Service |
| Technologie | Eine Sprache/ein Framework | Mix moeglich |
| Teamstruktur | Ein grosses Team | Mehrere kleine Teams |
| Komplexitaet | Im Code | In der Infrastruktur |
| Debugging | Einfacher (ein Prozess) | Schwieriger (verteiltes System) |
| Latenz | Funktionsaufrufe (schnell) | Netzwerk-Calls (langsamer) |
| Startzeit | Langsam bei grosser Codebasis | Schnell pro Service |
Kommunikation zwischen Microservices
Synchrone Kommunikation
Services kommunizieren direkt miteinander, typischerweise ueber REST APIs oder GraphQL:
- Client ruft API Gateway auf
- API Gateway routet an den zustaendigen Service
- Service antwortet synchron
Vorteil: Einfach zu implementieren und zu debuggen Nachteil: Enge Kopplung, kaskadierendes Failure-Risiko
Asynchrone Kommunikation
Services kommunizieren ueber Message Queues (RabbitMQ, Apache Kafka, Amazon SQS):
- Service A sendet eine Nachricht an die Queue
- Service B verarbeitet die Nachricht, wenn er bereit ist
- Keine direkte Abhaengigkeit zwischen den Services
Vorteil: Lose Kopplung, bessere Resilienz Nachteil: Hoehere Komplexitaet, eventuelle Konsistenz
Technologie-Stack fuer Microservices
Containerisierung
Docker ist der De-facto-Standard fuer die Paketierung von Microservices. Jeder Service wird als Container bereitgestellt, was konsistente Deployments ueber alle Umgebungen garantiert.
Orchestrierung
Kubernetes ist der Standard fuer die Verwaltung von Container-Clustern. Es uebernimmt:
- Auto-Scaling bei Lastspitzen
- Self-Healing bei Ausfaellen
- Service Discovery
- Load Balancing
Service Mesh
Tools wie Istio oder Linkerd fuegen eine Infrastrukturschicht hinzu, die Service-zu-Service-Kommunikation absichert, verschluesselt und ueberwacht -- ohne dass die Services selbst angepasst werden muessen.
Herausforderungen von Microservices
Distributed-System-Komplexitaet
Verteilte Systeme sind inhaerent komplex. Netzwerk-Latenzen, partielle Ausfaelle und Konsistenzprobleme existieren in Monolithen nicht in dieser Form.
Daten-Konsistenz
Wenn jeder Service seine eigene Datenbank hat, wird transaktionale Konsistenz zur Herausforderung. Patterns wie Saga und Event Sourcing helfen, bringen aber zusaetzliche Komplexitaet.
Monitoring und Debugging
Ein Request, der durch fuenf Services laeuft, ist schwerer zu debuggen als ein Funktionsaufruf im Monolithen. Distributed Tracing (Jaeger, Zipkin) und zentralisiertes Logging (ELK Stack) sind Pflicht.
Operativer Aufwand
Statt einer Anwendung muessen dutzende Services betrieben, ueberwacht und aktualisiert werden. CI/CD-Pipelines, Monitoring und Alerting multiplizieren sich.
Wann Microservices sinnvoll sind
Die beruemteste Empfehlung stammt von Martin Fowler: "Monolith First". Starten Sie mit einem Monolithen und brechen Sie ihn erst auf, wenn die Komplexitaet oder die Teamgroesse es erfordern. Microservices lohnen sich, wenn:
- Mehrere Teams unabhaengig an verschiedenen Teilen der Anwendung arbeiten
- Einzelne Komponenten unterschiedlich skaliert werden muessen
- Verschiedene Technologien fuer verschiedene Aufgaben optimal waeren
- Schnelle, unabhaengige Release-Zyklen noetig sind
Fuer die meisten Websites -- auch fuer professionelle Agentur-Websites mit Next.js und Headless CMS -- ist ein Monolith oder eine einfache Serverless-Architektur die bessere Wahl. Microservices entfalten ihre Staerke bei grossen, komplexen Systemen mit mehreren Entwicklerteams.