Published: Last updated:

Technology: Microservices

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.

Core Principles

  • 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.

When to Choose Microservices

Microservices machen Sinn wenn:

  1. Das Team auf 2-4 Teams gewachsen ist (Conway's Law).
  2. Einzelne Funktionen stark unterschiedliche Skalierungsanforderungen haben.
  3. Verschiedene Teams verschiedene Technologien einsetzen müssen.
  4. Der Deployment-Takt verschiedener Bereiche stark abweicht.

Focus: Autonomy Through 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. Startet mit einem gut strukturierten Modulith und extrahiert Services, wenn der Schmerz 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.

Reference Guide

Related Topics