Publiziert:

Microservices

Autonomie zählt mehr als verteilte Technik

Eine Microservices-Architektur strukturiert eine Anwendung als Sammlung kleiner, unabhängig deployierbarer Services, die jeweils eine klar abgegrenzte Geschäftsfunktion abdecken. Jeder Service kann unabhängig skaliert, deployed und mit einer eigenen Technologie implementiert werden.

Microservices sind kein Ziel an sich. Sie sind eine Antwort auf ein Problem: Wenn ein Monolith zu gross wird, um von einem einzelnen Team verstanden und betrieben zu werden.

Kernprinzipien

  • Single Responsibility: Jeder Service macht eine Sache und macht sie gut.
  • Decentralised Data Management: Jeder Service besitzt seine eigene Datenbank. Kein geteiltes Schema.
  • API-only Communication: Services kommunizieren ausschliesslich über APIs (REST, gRPC, Events).
  • Independent Deployability: Änderungen an einem Service erfordern kein Deployment anderer Services.
  • Design for Failure: Services rechnen damit, dass andere Services ausfallen. Resilience ist eingebaut.

Anti-Pattern: Distributed Monolith

Ein Distributed Monolith ist das schlimmste beider Welten: verteilte Komplexität ohne Autonomiegewinn. Entsteht, wenn Services scheinbar getrennt sind, aber enge Datenbank-Abhängigkeiten oder synchrone Aufrufketten bestehen.

Microservices zahlen sich unter vier Voraussetzungen aus

Microservices machen Sinn, wenn die Voraussetzungen zusammenkommen:

  1. Unabhängige Deploybarkeit ist gefordert: Teile sollen ohne Freigabe der übrigen ausgeliefert werden.
  2. Klare Bounded Contexts existieren, an denen sich Service-Grenzen ausrichten lassen (DDD, Conway's Law).
  3. Die nötige Betriebsreife ist vorhanden (Automatisierung, Observability, CI/CD), um verteilte Systeme zu betreiben.
  4. Der Druck auf Team-Autonomie wächst: einzelne Funktionen mit stark unterschiedlichen Skalierungs- oder Technologieanforderungen oder stark abweichendem Deployment-Takt.

Der Fokus: Autonomie durch Isolation

Der Hauptgewinn von Microservices ist Team-Autonomie. Technische Vorteile wie unabhängige Skalierung sind sekundär.

FAQ

Sollten wir mit Microservices starten?

Nein. Fast alle erfolgreichen Microservices-Architekturen begannen als Monolith. Der belastbare Einstieg ist ein gut strukturierter Modulith; Services werden erst extrahiert, wenn der Druck gross genug ist.

Wie gross soll ein Microservice sein?

Klein genug, dass ein Team ihn vollständig versteht und verantwortet. Gross genug, dass er eigenständig deploybar und wertvoll ist. Die DDD-Faustregel: ein Service pro Bounded Context.

Referenzen

Verwandte Themen