Wann sollte man von einem Monolithen zu Microservices migrieren (und wann nicht)

Die meisten Startups, die Microservices zu früh einführen, bereuen dies. Die meisten Unternehmen, die zu lange an Monolithen festhalten, bereuen dies. Die Frage ist nicht, was besser ist. Es ist der Zeitpunkt, an dem man wechseln muss.

In diesem Artikel werden die tatsächlichen Kompromisse zwischen monolithischen und Microservices-Architekturen behandelt, die Signale, die Ihnen sagen, dass es Zeit für eine Migration ist, die Signale, die Ihnen sagen, dass dies nicht der Fall ist, und der schrittweise Ansatz, der die häufigsten (und teuersten) Fehler vermeidet.

Was ein Monolith ist und warum er funktioniert

Ein Monolith ist eine einzelne einsetzbare Einheit. Eine Codebasis, eine Datenbank, eine Build-Pipeline, eine Bereitstellung. Ihr Authentifizierungsmodul, Ihr Abrechnungssystem, Ihr Benachrichtigungsdienst, Ihre API-Schicht; Sie befinden sich alle im selben Repository und werden gemeinsam bereitgestellt.

Das klingt einschränkend, aber für die meisten Teams ist das Gegenteil der Fall. Ein Monolith gibt dirGeschwindigkeit. Sie führen ein Refactoring über Modulgrenzen hinweg in einem einzigen Pull-Request durch. Sie führen eine Testsuite aus. Sie stellen ein Artefakt bereit. Sie debuggen, indem Sie einen Satz Protokolle lesen. Es gibt keine Netzwerklatenz zwischen Diensten, da keine Netzwerkaufrufe stattfinden. Es sind alles In-Process-Funktionsaufrufe.

Jedes erfolgreiche Technologieunternehmen begann als Monolith. Shopify betreibt eine monolithische Rails-App, die Transaktionen in Milliardenhöhe abwickelt. Stack Overflow bedient monatlich 100 Millionen Besucher aus einem Monolithen. Dies sind keine Unternehmen, die Microservices nicht verstehen konnten. Es handelt sich um Unternehmen, die verstanden haben, dass der Monolith das richtige Werkzeug für ihr Problem ist.

Wenn weniger als 20 Ingenieure an derselben Codebasis arbeiten, ist ein Monolith mit ziemlicher Sicherheit die richtige Wahl. Punkt.

Was Microservices sind und was sie kosten

Eine Microservices-Architektur unterteilt Ihre Anwendung in unabhängige Dienste. Jeder Dienst besitzt seine eigene Datenbank, stellt sie unabhängig bereit und kommuniziert mit anderen Diensten über APIs (typischerweise REST oder gRPC) oder Nachrichtenwarteschlangen.

Das Versprechen: Teams können unabhängig voneinander bereitstellen, einzelne Komponenten skalieren und unterschiedliche Technologien dort einsetzen, wo sie sinnvoll sind. Der Abrechnungsdienst kann so skaliert werden, dass er die Rechnungsverarbeitung am Monatsende abwickelt, ohne dass die gesamte Anwendung skaliert werden muss. Der Suchdienst kann Elasticsearch nutzen, während der Rest der App auf PostgreSQL läuft.

Die Kosten: Sie betreiben jetzt ein verteiltes System. Verteilte Systeme sind schwieriger aufzubauen, schwieriger zu testen und schwieriger zu debuggen. Hier erfahren Sie, wofür Sie sich anmelden:

• Netzwerkfehler zwischen Diensten.In einem Monolithen funktioniert ein Funktionsaufruf entweder oder löst eine Ausnahme aus. In Microservices kann eine Anfrage eine Zeitüberschreitung erfahren, eine Teilantwort zurückgeben oder stillschweigend fehlschlagen. Sie benötigen Wiederholungslogik, Leistungsschalter und Fallback-Strategien für jeden Anruf zwischen Diensten.
• Verteilte Transaktionen.Wenn ein einzelner Vorgang zwei Dienste umfasst (Kunden in Rechnung stellen und dann den Bestand aktualisieren), benötigen Sie Sagen oder eventuelle Konsistenzmuster. Der Aufbau ist komplex und das Debuggen aufwändig.
• Beobachtbarkeitsaufwand.Eine einzelne Anfrage kann 6 Dienste betreffen. Ohne verteiltes Tracing (Jaeger, Zipkin oder Datadog APM) bedeutet das Debuggen einer fehlgeschlagenen Anfrage das Durchsuchen von 6 separaten Protokollströmen in der Hoffnung, Zeitstempel zu korrelieren.
• Komplexität der Bereitstellung.Sie benötigen Container-Orchestrierung (Kubernetes oder ECS), Service Discovery, API-Gateways und CI/CD-Pipelines für jeden Service. Aus einer Pipeline werden 15.
• Herausforderungen bei der Datenkonsistenz.Jeder Dienst besitzt seine Datenbank. Das Zusammenführen von Daten zwischen Diensten erfordert API-Aufrufe, keine SQL-Joins. Die Berichterstellung wird zu einem Engineering-Projekt und nicht zu einer Abfrage.

Keines dieser Probleme ist unlösbar. Aber jedes einzelne erhöht den Entwicklungsaufwand, die Infrastrukturkosten und die betriebliche Komplexität, die ein Monolith nicht mit sich bringt.

Der Monolith ist in Ordnung, bis er es nicht mehr ist

Vier spezifische Signale zeigen Ihnen, dass Ihr Monolith über sich hinausgewachsen ist:

1. Stellen Sie Frequenzkonflikte bereit

Team A muss heute eine Abrechnungskorrektur versenden. Das halbfertige Feature von Team B befindet sich in derselben Bereitstellungspipeline und unterbricht die Bereitstellung. Team A wartet. Team B beeilt sich, seinen Code zu reparieren. Beide werden später als geplant ausgeliefert. Wenn das einmal im Monat passiert, ist das ein kleines Ärgernis. Wenn es zweimal pro Woche passiert, verlieren Sie Tage an Engineering-Zeit durch Koordinationsaufwand.

2. Teams treten aufeinander

Konflikte in gemeinsam genutzten Modulen zusammenführen. Zwei Teams ändern dasselbe Datenbankschema im selben Sprint. Codeüberprüfungen, die Kontext aus drei verschiedenen Funktionsbereichen erfordern. Dies sind Anzeichen dafür, dass Ihre Codebasis über das hinausgewachsen ist, was ein einzelnes Team besitzen kann. Wenn Ingenieure mehr Zeit mit Koordinieren als mit Programmieren verbringen, bremst Sie der Monolith aus.

3. Der Fehler eines Moduls zerstört alles

Ein Speicherverlust im Bildverarbeitungscode führt zum Absturz der gesamten Anwendung, einschließlich des Checkouts. Eine langsame Datenbankabfrage im Berichtsmodul verschlechtert die API-Antwortzeiten für alle Benutzer. In einem Monolithen teilen sich Module Ressourcen. Ein Ausfall einer Komponente überträgt sich auf alle anderen Komponenten. Wenn Ihr wichtigster Einnahmepfad (Bezahlvorgang, Zahlungen, Kern-API) durch Ausfälle in weniger kritischen Modulen beeinträchtigt wird, ist das ein klares Signal.

4. Die Skalierung einer Funktion bedeutet die Skalierung der gesamten App

Ihr Videotranskodierungsmodul benötigt das Achtfache der CPU Ihrer API-Ebene. Sie werden jedoch als eine Einheit bereitgestellt, sodass Sie 8x CPU für Ihre gesamte Anwendung ausführen, um die Anforderungen einer Komponente zu erfüllen. Ihre Infrastrukturrechnung ist 5- bis 10-mal höher als nötig, da Sie Komponenten nicht unabhängig voneinander skalieren können.

Wenn Sie regelmäßig zwei oder mehr dieser Signale bemerken, ist es an der Zeit, über die Extraktion nachzudenken. Keine vollständige Neufassung. Extraktion.

Anzeichen dafür, dass Sie NICHT bereit für Microservices sind

Bevor Sie mit der Planung einer Migration beginnen, prüfen Sie diese fünf Bedingungen. Wenn einer dieser Punkte zutrifft, bleiben Sie bei Ihrem Monolithen.

• Sie haben weniger als 5 Ingenieure.Microservices lösen Teamkoordinationsprobleme. Ein Dreierteam hat keine Koordinationsprobleme; Es verfügt über einen Slack-Kanal und ein Whiteboard. Der Overhead für den Betrieb einer verteilten Infrastruktur verbraucht 30–40 % der Kapazität Ihres kleinen Teams.
• Sie bedienen weniger als 10.000 Benutzer.Bei geringem Datenverkehr erledigt ein einzelner Server alles bequem. Microservices erhöhen die Latenz (Netzwerksprünge zwischen Diensten) und die Komplexität, ohne bei diesem Volumen nennenswerte Skalierungsvorteile zu bieten.
• Sie haben keine DevOps-Erfahrung im Team.Microservices erfordern Container-Orchestrierung, Service-Mesh-Konfiguration, verteilte Protokollierung und automatisierte Bereitstellungspipelines. Ohne jemanden, der diese Systeme in der Produktion bedient hat, werden Sie Monate damit verbringen, Infrastruktur statt Funktionen aufzubauen.
• Sie haben keine Überwachungs- oder Beobachtbarkeitsmöglichkeit.Wenn Sie eine Anfrage heute nicht durch Ihren Monolithen verfolgen können, können Sie sie morgen definitiv nicht über 10 Dienste hinweg verfolgen. Richten Sie strukturierte Protokollierung, Fehlerverfolgung (Sentry) und Überwachung der Anwendungsleistung (Datadog, New Relic) ein, bevor Sie etwas aufteilen.
• Sie haben in Ihrem Monolithen keine klaren Modulgrenzen definiert.Wenn Ihr Code ein verworrenes Netz ist, in dem das Abrechnungsmodul direkt aus der Benutzersitzungstabelle liest und das Benachrichtigungssystem in die Bestelldatenbank schreibt, wird das Extrahieren eines Dienstes ein Albtraum. Räumen Sie zuerst die Grenzen auf.

Der Migrationspfad: das Würgefeigenmuster

Der größte Fehler, den Teams machen, ist der Versuch, den Urknall neu zu schreiben. Sie verbringen 6–12 Monate damit, das gesamte System als Microservices neu aufzubauen, während der Monolith in der Produktion weiterläuft. Bis die Neufassung „abgeschlossen“ ist, verfügt der Monolith über 6–12 Monate an neuen Funktionen, die die Neufassung nicht bietet. Das Umschreiben holt nie auf. Das Projekt wird abgebrochen. Das Team ist demoralisiert.

Das Würgefeigenmuster vermeidet dies vollständig. Benannt nach dem Würgefeigenbaum, der um einen Wirtsbaum wächst und ihn nach und nach ersetzt, funktioniert dieser Ansatz in drei Schritten:

• Schritt 1:Identifizieren Sie eine zu extrahierende Komponente. Leiten Sie den Datenverkehr über ein API-Gateway oder einen Proxy weiter.
• Schritt 2:Bauen Sie den neuen Dienst neben dem Monolithen auf. Beide laufen gleichzeitig in der Produktion. Der Proxy leitet den Datenverkehr für die extrahierte Komponente an den neuen Dienst und für alles andere an den Monolithen weiter.
• Schritt 3:Sobald der neue Dienst 100 % seines Datenverkehrs zuverlässig abwickelt, entfernen Sie den alten Code aus dem Monolithen. Wiederholen Sie den Vorgang mit der nächsten Komponente.

Dieser Ansatz birgt ein geringes Risiko, da nie das gesamte System auf einmal ausgetauscht wird. Wenn der neue Dienst Probleme hat, leitet der Proxy den Datenverkehr zurück zum Monolithen. Benutzer bemerken es nie.

Was zuerst extrahiert werden soll

Für Ihre erste Extraktion haben Sie zwei gute Möglichkeiten:

Option A: Die Komponente, die sich am häufigsten ändert.Schauen Sie sich Ihr Git-Log an. Welches Verzeichnis hat in den letzten 6 Monaten die meisten Commits? Das ist die Komponente, die die meisten Bereitstellungskonflikte verursacht. Durch das Extrahieren erhalten Ihre Teams sofortige Unabhängigkeit bei der Bereitstellung.

Option B: Die Komponente, die eine unabhängige Skalierung benötigt.Wenn Ihr Videoverarbeitungsmodul das Zehnfache der Ressourcen Ihrer API-Ebene verbraucht, können Sie durch Extrahieren jede Komponente unabhängig skalieren (und bezahlen). Allein die Kosteneinsparungen können den Migrationsaufwand rechtfertigen.

Beginnen Sie nicht mit der komplexesten Komponente. Beginnen Sie nicht mit der Komponente, die die meisten Abhängigkeiten von anderen Modulen aufweist. Wählen Sie etwas mit einer klaren Grenze, einer klaren API-Oberfläche und einem Team, das bereit ist, es durchgängig zu übernehmen. Ihre erste Extraktion ist sowohl eine Lernübung als auch eine architektonische Verbesserung.

Häufige Fehler, die Microservices-Migrationen zum Scheitern bringen

Zu viele Dienste zu schnell extrahieren

Die Teams sind nach der ersten erfolgreichen Extraktion aufgeregt und versuchen, alles auf einmal aufzuteilen. Plötzlich führen sie 12 Dienste mit 12 Bereitstellungspipelines, 12 Protokollsätzen und 12 potenziellen Fehlerquellen aus. Die betriebliche Belastung überfordert das Team. Extrahieren Sie einen Service, führen Sie ihn vier bis sechs Wochen lang in der Produktion aus, lernen Sie aus den betrieblichen Herausforderungen und extrahieren Sie dann den nächsten.

Der verteilte Monolith

Dies ist der häufigste Fehlermodus. Sie teilen Ihre Anwendung in acht Dienste auf, die jedoch alle dieselbe Datenbank verwenden. Sie werden alle zusammen bereitgestellt, da Änderungen in einem Dienst Schemaänderungen erfordern, die sich auf die anderen auswirken. Sie verfügen über die gesamte betriebliche Komplexität von Microservices, ohne deren Vorteile. Jeder Dienst muss seine Daten vollständig besitzen. Wenn zwei Dienste dieselben Daten benötigen, kommunizieren sie über APIs oder Ereignisse und nicht über gemeinsam genutzte Tabellen.

Kein Service-Mesh oder Beobachtbarkeit

Das Ausführen von Microservices ohne verteiltes Tracing ist so, als würde man nachts mit ausgeschalteten Scheinwerfern fahren. Sie werden nicht bemerken, dass ein Dienst schlechter wird, bis sich Benutzer beschweren. Sie wissen nicht, welcher Dienst einen Fehler verursacht hat, ohne mehrere Protokollströme manuell zu durchsuchen. Bevor Sie Ihren ersten Dienst extrahieren, richten Sie verteilte Ablaufverfolgung, zentralisierte Protokollierung und Integritätsprüfungsendpunkte ein. Dies ist keine optionale Infrastruktur. Es ist eine Voraussetzung.

Kostenvergleich: Monolith vs. Microservices

Der Unterschied bei den Infrastrukturkosten zwischen diesen Architekturen ist erheblich und wird von den Teams immer wieder unterschätzt.

Diese Bereiche spiegeln Startups im mittleren Stadium und Unternehmen im Wachstumsstadium wider. Bereitstellungen im Unternehmensmaßstab können auf beiden Seiten höher ausgeführt werden.

Die Infrastrukturkosten sind der sichtbare Teil. Die versteckten Kosten sind die Entwicklungszeit. Ein Team, das Microservices betreibt, wendet 20–30 % seiner Kapazität für betriebliche Aufgaben auf: Aktualisierung von Kubernetes-Konfigurationen, Debuggen der Kommunikation zwischen Diensten, Verwaltung von Datenbankmigrationen über mehrere Dienste hinweg und Wartung von CI/CD-Pipelines. Das ist Entwicklungszeit, die nicht für Funktionen verwendet wird, die Ihren Benutzern wichtig sind.

Der „modulare Monolith“-Mittelweg

Es gibt eine dritte Option, die in den meisten Architekturartikeln außer Acht gelassen wird: der modulare Monolith. Sie behalten eine einzelne einsetzbare Einheit bei, erzwingen jedoch strenge Modulgrenzen darin.

Jedes Modul besitzt seine eigenen Datenbanktabellen (oder Schema). Module kommunizieren über klar definierte interne APIs, nicht indem sie auf die Datenbanktabellen anderer zugreifen oder private Funktionen aufrufen. Der Code ist so organisiert, dass das Extrahieren eines Moduls in einen eigenständigen Dienst eine Änderung der Transportschicht (von prozessinternen Funktionsaufrufen zu HTTP/gRPC) erfordert, ohne die Geschäftslogik neu zu schreiben.

Der modulare Monolith bietet Ihnen die meisten organisatorischen Vorteile von Microservices (klare Eigentumsverhältnisse, unabhängige Entwicklung innerhalb von Modulen, erzwungene Grenzen) ohne Betriebskosten. Sie stellen ein Artefakt bereit. Sie betreiben einen Datenbankserver. Sie durchsuchen einen Protokollstream.

Die Architektur von Shopify ist das bekannteste Beispiel. Sie führen eine monolithische Rails-App mit streng durchgesetzten Modulgrenzen aus. Wenn aus einem Modul ein Dienst werden muss (aufgrund von Skalierungsanforderungen oder Anforderungen an die Teamunabhängigkeit), ist die Extraktion unkompliziert, da die Grenzen bereits klar sind.

Für Teams zwischen 5 und 30 Ingenieuren ist der modulare Monolith oft die richtige Antwort. Sie erhalten die Struktur und Disziplin des Microservices-Denkens, ohne Infrastruktur- und Betriebssteuern zu zahlen.

Was Savi empfiehlt

Wir haben Monolithen, modulare Monolithen und Microservices-Architekturen für Kunden aus den Bereichen Fintech, E-Commerce und SaaS gebaut. Hier ist das Playbook, dem wir folgen:

• Beginnen Sie monolithisch.Jedes neue Produkt beginnt als Monolith. Die Priorität besteht darin, Funktionen bereitzustellen, den Markt zu validieren und schnell zu iterieren. Architektonische Reinheit spielt keine Rolle, wenn niemand Ihr Produkt verwendet.
• Setzen Sie Modulgrenzen vom ersten Tag an durch.Selbst in einem Monolithen sollte jedes Modul seine Daten besitzen und eine klare Schnittstelle bereitstellen. Dies kostet im Vorfeld fast nichts und erspart später monatelanges Refactoring.
• Richten Sie die Beobachtbarkeit frühzeitig ein.Strukturierte Protokollierung, Fehlerverfolgung und grundlegende Leistungsüberwachung. Sie benötigen dies, unabhängig davon, ob Sie monolithisch bleiben oder migrieren. Es sind Tischeinsätze.
• Extrahieren Sie Dienste nur, wenn spezifische Schmerzen auftreten.Bereitstellungskonflikte blockieren Releases. Ressourcenkonflikt zwischen Modulen. Der Aufwand für die Teamkoordination schmälert die technische Kapazität. Dabei handelt es sich um reale Signale, nicht um theoretische Bedenken.
• Verwenden Sie zum Extrahieren das Würgefeigenmuster.Ein Dienst nach dem anderen. Führen Sie es neben dem Monolithen entlang. Überprüfen Sie, ob es funktioniert. Fahren Sie dann mit dem nächsten fort. Schreiben Sie niemals eine Urknall-Umschreibung durch.
• Betrachten Sie den modularen Monolithen als Ihre langfristige Architektur.Für viele Produkte ist es das Beste aus beiden Welten. Sie wechseln nur dann zu echten Microservices, wenn die Beschränkung auf eine einzelne Bereitstellung des modularen Monolithen zum Engpass wird.

Die beste Architektur ist diejenige, die es Ihrem Team ermöglicht, die von Ihren Kunden gewünschten Funktionen bereitzustellen. Für die meisten Unternehmen ist das in den meisten Phasen ein gut strukturierter Monolith. Für einige Unternehmen handelt es sich an bestimmten Wendepunkten um eine gezielte Extraktion spezifischer Dienstleistungen. Für sehr wenige Unternehmen handelt es sich um eine vollständige Microservices-Architektur.

Wählen Sie Ihre Architektur nicht basierend auf dem, was Netflix oder Uber verwendet. Wählen Sie es basierend auf Ihrer Teamgröße, Ihren Verkehrsmustern, Ihrer Bereitstellungshäufigkeit und den spezifischen Engpässen aus, auf die Sie heute stoßen. Nicht die Engpässe, auf die Sie in zwei Jahren stoßen könnten.

Häufig gestellte Fragen