Was ist Microservices Architektur? Unterschied zum Monolithen
Was ist Microservices Architektur?
Microservices Architektur ist ein Ansatz, bei dem Sie eine Anwendung in viele kleine Dienste zerlegen. Jeder Dienst übernimmt genau eine fachliche Aufgabe, lässt sich unabhängig ausliefern und besitzt seine eigenen Daten. Die Dienste sprechen über klar definierte Schnittstellen und Ereignisse miteinander, deshalb müssen Sie nicht jedes Mal die gesamte Anwendung neu ausliefern.
Stellen Sie sich einen Basar neben einem Kaufhaus vor. Der Monolith ist das Kaufhaus: ein Gebäude, eine Leitung, alles unter einem Dach. Microservices gleichen dem Basar, denn dort betreibt jeder Stand sein eigenes Geschäft. Schließt ein Stand, handeln also die anderen weiter. Allerdings braucht ein Basar mehr Abstimmung als ein einzelnes Kaufhaus.
In diesem Leitfaden erklären wir, was ist Microservices Architektur, in einfacher Sprache. Zunächst sehen Sie die Definition und den Vergleich mit dem Monolithen. Danach wägen wir Vorteile und Kosten ab, zeigen, warum der Ansatz für kleine Teams oft zu früh kommt, und beschreiben die schrittweise Migration. Eine Checkliste für die Entscheidung schließt den Beitrag ab.
Was ist Microservices Architektur im Vergleich zum Monolithen, und wo liegt der Unterschied?
Ein Monolith ist eine Anwendung, deren Funktionen in einer einzigen Codebasis liegen und als ein Paket live gehen. Microservices dagegen zerlegen dieses Paket in unabhängige Teile. Dazwischen steht eine dritte Option, der modulare Monolith. Er geht weiterhin als ein Stück live, hat aber zudem intern klare Modulgrenzen.
| Kriterium | Monolith | Modularer Monolith | Microservices |
|---|---|---|---|
| Auslieferungseinheit | Gesamte Anwendung | Gesamte Anwendung | Jeder Dienst einzeln |
| Codegrenzen | Schwach, sie verwischen mit der Zeit | Klare Regeln zwischen Modulen | Das Netzwerk erzwingt sie |
| Daten | Meist eine Datenbank | Eine Datenbank, je Modul ein Schema | Jeder Dienst besitzt seine Daten |
| Skalierung | Alles gemeinsam | Alles gemeinsam | Je Dienst getrennt |
| Betriebsaufwand | Niedrig | Niedrig | Hoch |
| Tempo am Anfang | Hoch | Hoch | Geringer, Infrastruktur nötig |
| Passt am besten zu | Neuem Produkt, kleinem Team | Wachsendem Produkt, einem Team | Vielen Teams, unabhängigen Releases |
Lesen Sie die Tabelle so: Die linke Seite bringt Einfachheit, die rechte Seite bringt Eigenständigkeit. Deshalb lautet die eigentliche Frage nicht, welcher Stil moderner ist. Entscheidend ist also, welcher Stil heute zu Ihrem Team und Ihrem Produkt passt.
Was genau umfasst ein einzelner Microservice?
Ein Microservice ist ein kleines Programm, das eine fachliche Aufgabe von Anfang bis Ende übernimmt. In einem Onlineshop können zum Beispiel Bestellung, Lager und Zahlung getrennte Dienste sein. Außerdem hat jeder eigenen Code, eine eigene Datenbank und eine eigene Auslieferungsstrecke. Andere Dienste schauen nie hinein, denn sie rufen nur die Schnittstelle auf.
Die Dienstgrenze zu ziehen, ist der schwierigste Teil des Entwurfs. Das Architekturzentrum von Microsoft Azure rät dazu, Grenzen entlang der Fachdomäne zu legen. Der Schlüsselbegriff lautet Bounded Context, also abgegrenzter Kontext. Das heißt, gemeint ist der Bereich einer Domäne, in dem jedes Wort genau eine Bedeutung hat. Zum Beispiel braucht der „Kunde“ im Bestelldienst nicht dieselben Felder wie der „Kunde“ in der Abrechnung.
Für die Größe gibt es außerdem keine magische Zeilenzahl. Besser ist dieser Test: Kann ein kleines Team den Dienst allein verstehen, bauen und ausliefern? Lautet die Antwort ja, stimmt die Größe also vermutlich.
Wie sprechen Microservices miteinander?
Dienste kommunizieren auf zwei Grundwegen, synchron und asynchron. Zunächst ruft beim synchronen Weg ein Dienst einen anderen auf und wartet auf die Antwort. Beim asynchronen Weg veröffentlicht ein Dienst ein Ereignis, und interessierte Dienste verarbeiten es in ihrem eigenen Tempo. Dennoch haben beide Wege ihren Platz.
| Merkmal | Synchron (API Aufruf) | Asynchron (Ereignis oder Nachricht) |
|---|---|---|
| Ablauf | Anfrage, Warten, Antwort | Ereignis wird abgelegt, Empfänger liest später |
| Abhängigkeit | Der gerufene Dienst muss laufen | Dienste hängen zeitlich nicht aneinander |
| Fehlerwirkung | Kann sich entlang der Kette ausbreiten | Nachricht wartet in der Warteschlange |
| Nachvollziehbarkeit | Einfach, der Ablauf ist klar | Schwerer durchgängig zu verfolgen |
| Typischer Einsatz | Sofortige Abfragen, Antworten an Nutzer | Benachrichtigungen, Hintergrundjobs, Integrationen |
Martin Fowler beschreibt dieses Prinzip mit dem Satz „smarte Endpunkte, dumme Leitungen“. Das heißt, die Intelligenz bleibt in den Diensten, und der Kommunikationskanal bleibt schlicht. Die Ereignisseite vertiefen wir im Beitrag Was ist Event Driven Architecture.
Auf der synchronen Seite ist REST allerdings nicht die einzige Wahl. Zum Beispiel benennt der Client mit GraphQL selbst die Felder, die er braucht. Beide Stile vergleichen wir in Was ist GraphQL und wie unterscheidet es sich von REST.
Was leisten API Gateway und Service Discovery?
Ein API Gateway ist die zentrale Eingangstür für Clients. Statt die Adressen von Dutzenden Diensten zu kennen, schickt ein Client seine Anfrage an das Gateway. Dann leitet dieses den Aufruf an den richtigen Dienst weiter. Außerdem übernimmt es gemeinsame Aufgaben wie Authentifizierung, Protokollierung und Lastverteilung.
Service Discovery löst ein anderes Problem. Denn Dienste starten und stoppen laufend, und ihre Adressen ändern sich. Damit ein Dienst einen anderen findet, braucht er ein aktuelles Adressbuch. Orchestrierungsplattformen wie Kubernetes liefern das mit, und die offizielle Dokumentation erklärt das Service Konzept im Detail.
Der Azure Leitfaden warnt zudem vor einem Fehler: Halten Sie Fachlogik aus dem Gateway heraus. Kurz gesagt soll das Gateway nur weiterleiten und gemeinsame Aufgaben erledigen. Sickern Geschäftsregeln ein, entsteht ein neuer Engpass, der Ihre Dienste miteinander verkoppelt.
Warum sollte jeder Dienst seine eigenen Daten besitzen?
Teilen sich Dienste eine Datenbank, besteht ihre Unabhängigkeit nur auf dem Papier. Ändert ein Team eine Tabelle, gehen daher die anderen kaputt. Daher speichert in einer Microservices Architektur jeder Dienst seine Daten selbst. Stattdessen erreichen alle anderen diese Daten nur über die Schnittstelle des Dienstes.
Der Preis ist die Datenkonsistenz. Zum Beispiel läuft in einer einzelnen Datenbank eine Transaktion entweder ganz oder gar nicht. Über mehrere Dienste hinweg lässt sich diese Garantie dagegen nicht so leicht geben. Deshalb lernen Sie, mit eventueller Konsistenz zu leben. Das heißt, Daten weichen kurz voneinander ab und gleichen sich bald wieder an.
In der Praxis verlangt das Sorgfalt bei Dubletten. Kommt zum Beispiel dieselbe Nachricht zweimal an, darf sich das Ergebnis nicht ändern. Diese Eigenschaft behandeln wir in Was ist Idempotenz. Außerdem stützt sich fast jede Integration zwischen Diensten darauf.
Brauchen Dienste gemeinsame Daten, haben Sie zwei Möglichkeiten. Erstens fragen Sie den Besitzer über seine Schnittstelle. Zweitens halten Sie eine kleine lokale Kopie, die sich aus Ereignissen aktualisiert. Der Azure Leitfaden nennt es allerdings einen Anti Pattern, jede Duplizierung zu vermeiden. Wichtig ist, dass alle den einen Besitzer jedes Datums kennen.
Welche echten Vorteile bieten Microservices?
Die Vorteile sind real, allerdings hängt jeder an einer Bedingung. Der Azure Leitfaden und Fowlers Artikel nennen ähnliche Punkte. Daher fasst die folgende Liste sie zusammen:
- Unabhängige Releases: Sie liefern einen Dienst aus, ohne auf die anderen zu warten, und rollen ihn allein zurück.
- Unabhängige Skalierung: Sie geben nur dem belasteten Dienst mehr Ressourcen.
- Teamautonomie: Kleine Teams besitzen ihre Dienste vom Entwurf bis zum Betrieb.
- Fehlerisolation: Ein Dienst kann ausfallen, während der Rest der Anwendung weiterläuft.
- Technologiefreiheit: Jeder Dienst kann die Sprache oder Datenbank nutzen, die am besten passt.
- Kleine Codebasen: Ein neuer Entwickler versteht einen Dienst schneller als einen ganzen Monolithen.
Nehmen wir die unabhängige Skalierung als Beispielszenario. Konkret wird an Aktionstagen nur die Bestellannahme voll, während das Reporting ruhig bleibt. Beim Monolithen müssen Sie die ganze Anwendung vervielfachen. Mit Microservices vervielfachen Sie dann nur den Bestelldienst. Somit nutzen Sie Ressourcen gezielter und verschwenden weniger.
Der kritische Punkt lautet: Diese Vorteile treten nur auf, wenn die Grenzen gut gezogen sind. Bei falschen Grenzen werden also aus den Vorteilen schlicht Zusatzkosten.
Welche versteckten Kosten haben Microservices?
Jeder Dienst ist für sich einfach, allerdings ist das Gesamtsystem komplexer. Mit Fowlers Worten verschwindet Komplexität also nicht, sie wandert. Verbindungen, die früher im Code lagen, laufen nun über das Netzwerk, und das Netzwerk ist nie völlig verlässlich.
- Netzwerkfehler: Entfernte Aufrufe können langsam sein, in ein Timeout laufen oder nie antworten.
- Datenkonsistenz: Eine einzelne Garantie deckt keinen Vorgang ab, der mehrere Dienste umfasst.
- Testaufwand: Abhängige Dienste gemeinsam zu prüfen, ist schwerer als eine Anwendung zu testen.
- Versionierung: Ändern Sie eine Schnittstelle, dürfen Sie die Aufrufer nicht brechen.
- Betriebsaufwand: Viele Dienste auszuliefern, zu beobachten und zu aktualisieren, kostet zusätzliche Arbeit.
- Kompetenzbedarf: Ihr Team braucht echte Erfahrung mit verteilten Systemen.
Wir nennen diese Kosten nicht, um Sie abzuschrecken. Stattdessen sollen Sie ehrlich entscheiden können. Zum Beispiel fällt das Bild für ein Team, das sie tragen kann, womöglich positiv aus. Für ein Team, das sie nicht tragen kann, ist eine einzelne Anwendung meist sicherer.
Allerdings zeigen sich manche Kosten erst spät. Im ersten Monat läuft alles glatt, denn es gibt nur wenige Dienste. Wächst die Zahl dann, treten Versionskonflikte, wachsende Konfigurationsdateien und längere Fehlersuchen auf. Deshalb lohnt es sich, früh Standards zu setzen.
Warum ist Monitoring in einem verteilten System unverzichtbar?
Zunächst: In einer einzelnen Anwendung öffnen Sie bei einem Fehler ein Protokoll. Bei Microservices dagegen kann eine Nutzeranfrage durch fünf oder sechs Dienste laufen. Um die Fehlerstelle zu finden, müssen Sie also die Anfrage von Anfang bis Ende verfolgen. Daher heißt diese Praxis verteiltes Tracing.
Zudem bilden zentrale Protokolle, Metriken und Traces zusammen die Observability. Der Azure Leitfaden verweist dafür auf gemeinsame Frameworks wie OpenTelemetry. Das Thema behandeln wir in Was ist Observability und OpenTelemetry.
Ohne Monitoring auf Microservices umzusteigen, gleicht der Arbeit in einem dunklen Keller. Sie spüren zwar, dass etwas nicht stimmt, sehen aber nicht, wo. Daher empfehlen wir, die Beobachtung zusammen mit dem ersten Dienst aufzubauen.
Die wichtigsten Signale sind einfach: Anzahl der Anfragen, Fehlerrate und Antwortzeit. Legen Sie diese drei dann je Dienst auf ein Dashboard. Ein Alarm bei ungewöhnlicher Veränderung zeigt Ihnen Probleme, bevor Ihre Nutzer sie bemerken.
Wie läuft der Release Prozess bei Microservices ab?
Mit wachsender Dienstzahl skalieren manuelle Releases nicht mehr. Deshalb braucht jeder Dienst eigene automatische Tests und eine eigene Auslieferungsstrecke. So erreicht eine Änderung in einem Dienst die Produktion unabhängig von den anderen. Der Azure Leitfaden nennt CI/CD Pipelines als Kernpraxis.
Continuous Integration und Continuous Delivery erklären wir im Beitrag Was ist CI/CD. Kurz gesagt: Steigen Sie ohne automatische Pipeline nicht auf Microservices um. Die Pipeline ist kein Luxus, sondern Voraussetzung dafür, dass die Architektur funktioniert.
Außerdem helfen Vertragstests. Konkret schreiben Sie Tests, die prüfen, was ein Dienst von einem anderen erwartet. Dann sieht ein Team vor dem Release, ob seine Änderung die Aufrufer bricht.
Welche Programmiersprache passt zu welchem Dienst?
Ein Versprechen der Microservices lautet, dass jeder Dienst eine andere Technologie nutzen darf. In der Theorie ist diese Freiheit großartig. In der Praxis erschweren zu viele Sprachen und Frameworks aber die Wartung. Der Azure Leitfaden rät deshalb, Technologieentscheidungen zu begrenzen und gemeinsame Standards zu setzen.
Zum Beispiel kann ein Team eine Hauptsprache nutzen und nur für einen wirklich anderen Bedarf eine zweite ergänzen. Zum Beispiel vergleichen wir zwei beliebte Backend Optionen im Vergleich von Python und Go für das Backend. Am Ende hängt die Wahl von den Fähigkeiten Ihres Teams und von der Art der Aufgabe ab.
Begrenzte Sprachvielfalt hält außerdem Ihr Team flexibel. Kennen alle dieselben zwei Sprachen, wechseln Entwickler also leicht zwischen Diensten. Ein Dienst in einer seltenen Sprache kann dagegen zur kleinen Wissensinsel werden.
Was ist Microservices Architektur für kleine Teams, und wann ist sie zu früh?
Hier die ehrliche Antwort auf die Frage, was ist Microservices Architektur: Sie ist eine Lösung für die Organisation von Teams. Denn der Stil entstand, damit viele Teams arbeiten können, ohne aufeinander zu warten. Für ein kleines Team bringt er meist mehr Last, als er abnimmt.
Fowler empfiehlt, mit einem Monolithen zu beginnen, ihn modular zu halten und erst bei einem echten Problem zu zerlegen. Der Grund ist einfach. Denn Dienstgrenzen, die man bei unklarer Domäne zieht, sind meist falsch. Außerdem kostet es weit mehr, einen falsch gezogenen Dienst zu verschieben, als ein Modul zu verschieben.
- Ist das Team klein und versteht jeder die Codebasis, sind Microservices zu früh.
- Verändert sich die Fachdomäne noch schnell, sind Microservices zu früh.
- Fehlen automatische Tests, Release Pipeline und Monitoring, sind Microservices zu früh.
- Blockiert ein Release immer wieder mehrere Teams, lohnt sich ein ernsthafter Blick auf Microservices.
Kurz gesagt ist diese Liste eine Faustregel, kein Gesetz. Jedes Projekt hat weitere Faktoren, die Sie abwägen müssen. Bedenken Sie zudem, dass zwischen Monolith und Microservices keine Einbahnstraße liegt. Ein gut strukturierter Monolith dient Ihnen heute und lässt sich später zerlegen. Eine zu frühe Zerlegung wieder zusammenzuführen, ist dagegen deutlich mühsamer.
Wie prägt das Conway Gesetz Ihre Architektur?
Das Conway Gesetz besagt, dass eine Organisation Systeme baut, die ihre Kommunikationsstruktur spiegeln. Daher greift Fowler diese Idee auf. Teilen Sie Teams nach Schichten, mit einem für die Oberfläche, einem für den Server und einem für die Datenbank, braucht jede kleine Änderung die Abstimmung von drei Teams.
Der Microservices Ansatz dreht das dagegen um. Teams bilden sich entlang fachlicher Aufgaben, und jedes Team besitzt seinen Dienst von Anfang bis Ende. Ein Team entwirft, baut, liefert aus und betreibt eine Funktion. Entscheidungen fallen schneller, weil die Wartekette reißt.
Betrachten Sie Architektur daher nicht als rein technisches Thema. Anders gesagt ist Ihr Organigramm der erste Entwurf Ihrer Architektur. Sind Ihre Teams noch nicht reif genug für unabhängiges Arbeiten, verlagert die Trennung der Dienste das Abstimmungsproblem nur ins Netzwerk.
Wann ist der Umstieg auf Microservices sinnvoll?
Es gibt klare Signale. Erstens blockieren sich wachsende Teams gegenseitig bei Releases. Zweitens braucht ein Teil der Anwendung deutlich mehr Ressourcen als der Rest. Drittens ändern sich verschiedene Teile mit unterschiedlichem Tempo und unterschiedlichem Risiko.
Ein Beispielszenario: In einer Shop Anwendung ändert sich das Zahlungsmodul selten, ist aber sehr sensibel. Das Modul für Aktionen und Schaufenster ändert sich dagegen jede Woche, also ständig. Beide an einen Release Zyklus zu binden, bremst beide. Das Zahlungsmodul abzutrennen, kann dann ein sinnvoller erster Schritt sein.
Zunächst messen Sie das Problem, bevor Sie trennen. Schauen Sie auf Wartezeiten bei Releases, Fehlerquellen und Ressourcenverbrauch. Überzeugen Sie die Zahlen nicht, liegt die Ursache vielleicht im Prozess und nicht in der Architektur. Zum Beispiel bringen bessere Tests oder klare Code Verantwortung oft große Entlastung, auch ohne Migration.
Wie wechseln Sie mit dem Strangler Fig Muster vom Monolithen zu Microservices?
Mit dem Strangler Fig Muster ersetzen Sie ein Altsystem schrittweise, statt es auf einmal abzureißen. Der Name stammt nämlich von Würgefeigen, die auf einem Baum wachsen und ihn langsam ersetzen. Martin Fowler nutzte dieses Bild für die Modernisierung alter Systeme.
- Erstens setzen Sie eine Routing Schicht vor die alte Anwendung.
- Zweitens wählen Sie das erste Stück zum Herauslösen. Eine Fähigkeit mit geringem Risiko und klarer Grenze ist der ideale Start.
- Bauen Sie dieses Stück als neuen Dienst und leiten Sie seinen Verkehr über die Routing Schicht.
- Schalten Sie den passenden Code in der alten Anwendung ab und beobachten Sie das Ergebnis.
- Wiederholen Sie diese Schritte und verschieben Sie die Teile nacheinander.
- Hat die alte Anwendung ihre Aufgabe erfüllt und ist geschrumpft, schalten Sie sie ab.
Die Stärke dieser Methode liegt daher in ihrer Umkehrbarkeit. Jeder Schritt ist klein, daher stellen Sie bei einem Problem das Routing einfach auf den alten Weg zurück. Sie erhalten so einen stetigen, kontrollierten Wandel statt eines großen Knalls.
Fragen Sie bei der Wahl des ersten Stücks: Welcher Teil hat wenige Abhängigkeiten und bringt nach der Trennung schnellen Nutzen? Randaufgaben wie Benachrichtigungen oder Reporting eignen sich zum Beispiel meist gut. Die Kernlogik verschieben Sie dann erst, nachdem Sie Erfahrung gesammelt haben.
Welche Fehler treten bei Microservices am häufigsten auf?
Der häufigste Fehler ist ein Monolith im Microservices Gewand. Man nennt ihn verteilten Monolithen. Die Dienste gehen getrennt live, hängen aber so eng zusammen, dass eine Änderung alle anderen mitzieht. Dann erleben Sie die Probleme beider Welten.
- Gemeinsame Datenbank: Schreiben Dienste in dieselbe Tabelle, ist die Unabhängigkeit dahin.
- Zu feine Zerlegung: Jede kleine Funktion zum Dienst zu machen, lässt Netzwerklast und Komplexität explodieren.
- Geschwätzige Schnittstellen: Rufen sich zwei Dienste ständig gegenseitig auf, liegt die Grenze womöglich falsch.
- Kopplung über gemeinsame Bibliotheken: Binden Sie Dienste an denselben Code, wird jede Änderung riskant.
- Fachlogik im Gateway: Die Eingangstür darf die Arbeit der Dienste nicht übernehmen.
Der Azure Leitfaden führt diese Muster unter den Anti Patterns auf. Gemeinsam ist ihnen, dass sie das, was Sie trennen wollten, heimlich wieder verbinden.
Wo passen Docker und Kubernetes ins Bild?
Ein Container ist eine tragbare Einheit, die einen Dienst samt Abhängigkeiten verpackt. Der Dienst läuft dann in jeder Umgebung gleich. Docker ist der bekannteste Weg, Container zu bauen. Die Grundlagen finden Sie in Was ist Docker.
Viele Container von Hand zu verwalten, ist mühsam. Orchestrierungsplattformen übernehmen das: Sie verteilen Dienste auf Maschinen, starten abgestürzte neu und skalieren sie mit der Last. Kubernetes ist das bekannte Werkzeug dafür. Den Unterschied erklären wir in Docker und Kubernetes im Vergleich.
Eine wichtige Warnung: Kubernetes ist für Microservices nicht zwingend. Für kleine Anfänge reichen oft einfachere Hosting Optionen. Lassen Sie die Infrastrukturkomplexität nicht vor Ihrem echten Bedarf herlaufen.
Container vereinfachen außerdem die Entwicklung. Ein neuer Entwickler startet einen Dienst samt Abhängigkeiten auf dem Laptop, ohne manuelle Einrichtung. Das beendet manche Diskussion nach dem Motto „bei mir lief es noch“.
Wie funktionieren Sicherheit und Authentifizierung zwischen Diensten?
Mit der Zahl der Dienste wächst auch die Angriffsfläche. Denken Sie deshalb in Schichten, statt sich auf einen einzigen Punkt zu verlassen. Das Gateway kann die Identität der Clients prüfen. Den Verkehr zwischen Diensten verschlüsseln Sie mit Verfahren wie gegenseitigem TLS.
Ein gängiger Weg, Identität zwischen Diensten zu transportieren, ist ein signiertes Token. Diesen Aufbau erklären wir konzeptionell in Was ist ein JWT. Der Azure Leitfaden empfiehlt, die Token Prüfung in eine eigene Komponente zu legen, statt sie in jeden Dienst einzubauen.
Ein kurzer Hinweis: Dieser Abschnitt ist ein allgemeiner Rahmen. Prüfen Sie für Ihr eigenes System Bedrohungsmodell und Compliance Anforderungen gemeinsam mit qualifizierten Fachleuten.
Mit welchen Nachbarbegriffen verwechselt man Microservices?
In der Architektur gibt es viele ähnliche Konzepte. Die folgende Tabelle trennt die am häufigsten verwechselten. Details zu jedem finden Sie in den verlinkten Beiträgen.
| Begriff | Kurzbedeutung | Verhältnis zu Microservices |
|---|---|---|
| SOA (serviceorientierte Architektur) | Wiederverwendung von Diensten im Unternehmen | Ältere Idee, die oft eine zentrale Kommunikationsschicht nutzt |
| Event Driven Architecture | Dienste kommunizieren über Ereignisse | Wird oft kombiniert, ist aber ein eigenes Konzept |
| Serverless | Der Anbieter betreibt die Server | Eine Betriebsart für Dienste, kein Architekturstil |
| Micro Frontends | Oberfläche in unabhängige Teile zerlegen | Dieselbe Logik, angewendet auf das Frontend |
| Modularer Monolith | Ein Release, klare interne Grenzen | Ein sicherer Zwischenschritt hin zu Microservices |
Wenn Sie die Oberflächenseite interessiert, lesen Sie Was sind Micro Frontends.
Welche Checkliste sollten Sie vor der Entscheidung durchgehen?
Beantworten Sie die folgenden Fragen ehrlich. Fehlen mehrere Punkte, ist es klüger, diese zuerst zu klären, statt sofort auf Microservices zu springen.
- Welches messbare Problem wollen Sie lösen, und kann ein Monolith es nicht lösen?
- Haben sich Fachdomäne und Dienstgrenzen ausreichend gesetzt?
- Können Sie für jeden Dienst automatische Tests und eine Release Pipeline aufbauen?
- Sind zentrale Protokolle, Metriken und verteiltes Tracing bereit?
- Akzeptieren Sie, dass jeder Dienst seine Daten besitzt und Konsistenz eventuell ist?
- Hat Ihr Team Erfahrung mit verteilten Systemen, oder haben Sie Lernzeit eingeplant?
- Gibt es einen Migrationsplan, dessen erster Schritt klein und umkehrbar ist?
Antworten Sie bei den meisten Punkten mit nein, ist ein modularer Monolith eine starke Wahl. Er schärft die Grenzen im Code, erleichtert eine spätere Trennung und hält Ihren Betriebsaufwand heute niedrig.
Welchen Weg sollten Sie also wählen?
Kurz gesagt lautet die Antwort auf die Frage, was ist Microservices Architektur: eine Sammlung kleiner, unabhängiger Dienste mit eigenen Daten. Der Stil glänzt in großen Systemen mit vielen Teams und schnellem Wandel. Für kleine Teams und unklare Domänen ist er dagegen oft eine unnötige Last.
Wirken diese Themen noch fremd, sorgen Sie sich nicht. Gute Architekturentscheidungen beginnen mit einer klaren Bedarfsanalyse. Wir von Talha Aslan und Team prüfen gern mit Ihnen, welche Architektur zur Größe Ihres Projekts passt; werfen Sie dazu einen Blick auf unsere individuelle Softwareentwicklung. Dieser Beitrag ersetzt keine Ingenieurberatung, entscheiden Sie also in Ihrem eigenen Kontext.
Als Quellen empfehlen wir Martin Fowlers Artikel zu Microservices, den Microservices Leitfaden des Microsoft Azure Architecture Center und den Beitrag Strangler Fig Application. Zur Service Discovery lesen Sie die offizielle Kubernetes Dokumentation zu Services.
