Microservices

Stell dir ein riesiges Schweizer Taschenmesser vor, das 10 Kilo wiegt (Monolith). Es hat Löffel, Säge, Lupe und Zange. Wenn die Säge bricht, musst du das ganze Messer zur Reparatur geben. Du hast keinen Löffel mehr.

Microservices ist, als hättest du einen Werkzeugkasten mit vielen einzelnen Werkzeugen.

Ein Löffel.
Eine Säge.
Eine Zange. Wenn die Säge kaputt ist, tauschst du nur die Säge aus. Der Löffel funktioniert weiter. Jedes Werkzeug macht nur eine Sache, aber die macht es perfekt.

Merksatz: Ein Architekturstil, bei dem eine App in viele kleine, unabhängige Dienste zerlegt wird.

Amazon.com ist nicht eine Webseite. Es sind hunderte Microservices.

Service A: Zeigt Produkte an.
Service B: Verwaltet den Warenkorb.
Service C: Schreibt Rechnungen.
Service D: Empfiehlt ähnliche Produkte.

Vorteile:

Team A kann den Warenkorb verbessern, ohne mit Team C (Rechnungen) reden zu müssen.
Wenn der "Empfehlungs-Service" abstürzt, geht Amazon trotzdem noch (du siehst nur keine Empfehlungen). In einem Monolithen würde der ganze Shop abstürzen.

Praxisroutine

In der Praxis lernst du Microservices, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Kommunikation (REST / gRPC)

Die Services müssen reden. "Hey Rechnungsservice, User X hat bestellt." Das passiert meistens über APIs (REST oder gRPC) oder über Nachrichten (Message Queues wie Kafka). Das Netzwerk wird zur kritischen Komponente.

2. Spaghetti-Architektur

Die Gefahr: Wenn du 500 Services hast, weiß keiner mehr, wer wen aufruft. "Ich hab Service A geändert, warum geht Service Z nicht mehr?" Man braucht extrem gutes Monitoring (Observability), um den Überblick zu behalten ("Wer redet mit wem?").

Technische Einordnung im System

Technisch ist Microservices nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. CAP Theorem und Distributed Data

In einem SQL-Monolithen hast du "ACID"-Garantien (Transactions). Wenn der Ticket-Kauf klappt, sinkt die User-Balance. Klappt etwas nicht, rollt die gesamte Datenbank zurück. Microservices zerreißen das: Der Checkout-Service verwaltet eine MongoDB, der Balance-Service eine Postgres. Das CAP-Theorem (Consistency, Availability, Partition Tolerance) diktiert, dass man bei Netzwerkbrüchen wählen muss. Entweder der Shop nimmt kein Ticket an (Availability stirbt), oder man akzeptiert asynchrone Konsistenz (Eventual Consistency). Die Ticket-Bestellung feuert Kafka-Events ab (TicketCreated). Der Payment-Service konsumiert sie asynchron. Wenn der Payment Service 3 Stunden offline ist, sitzt die Buchung in Kafka in der Queue und wird final verarbeitet ("Saga-Pattern"), sobald Payment rebootet. Strikte "Transaktionen" sind tot, asynchrone Kompensation ist der King.

2. Das API Gateway Pattern (Backend for Frontend)

Wenn der iOS Client das Profil, die letzten 5 Käufe und die Favoriten eines Users abrufen möchte, muss er im Microservice-Backend bei roher Architektur nun 3 externe Service-HTTP-Calls ins WAN jagen. Bei 3G-Netz ein Performance-Wahnsinn (Chatty Client). Die Lösung ist das API Gateway. Das Gateway ist der einzige exponierte Public-Port. Das iPhone sendet exakt einen Request. Das Gateway bündelt die Anfrage (Fanning) auf dem ultra-schnellen internen Layer-2-Netz ins Rechenzentrum der 3 Services, aggregiert die 3 JSON-Antworten zu einem Mega-Block, und sendet ihn ans iPhone. Weiterer Vorteil: Das Gateway regelt Auth, Rate-Limiting und Cross-Origin Resource Sharing (CORS) zentral für jegliche dahinterliegende 500 Services.

3. Conway's Law

Warum spalten Firmen Software in Services? Nicht wegen Serverkosten. Wegen HR! "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." (Conway's Law, 1967). Wenn Firma 5 stark getrennte Abteilungen (Billing, Auth, Ads, SEO, Content) hat, die nie miteinander sprechen, wird ihr gebauter Software-Monolith in Kürze kollabieren, weil Code im git bei Merges kollidert. Microservices erlauben es der Firma 5 isolierte Repositorys ("Bounded Contexts" im Domain-Driven Design) zu gründen. Das Ad-Team deployt ihren Node.js Microservice freitags 14 Uhr, ohne dass das Billing-Team (welches in Java baut und quartalsweise veröffentlich) jemals beeinträchtigt oder überhaupt informiert werden muss.