Ein Dienst oder viele: wann man aufteilt
Warum ein Monolith kein Schimpfwort ist
Ein System ist leichter zu deployen, zu debuggen und über Domänen hinweg zu ändern. Die meisten früh aufgeteilten Projekte bekamen die vollen Kosten der Aufteilung — Netz, Versionen, verteilte Überwachung, Konsistenz — bevor sie einen Nutzen daraus zogen.
Zeichen, dass es Zeit ist
Eine Veröffentlichung blockiert, weil Teams aufeinander warten; eine Komponente mit völlig anderem Ressourcenbedarf; ein Teil, der ein separates Verfügbarkeitsniveau oder eine Regulierung erfordert; eine sehr unterschiedliche Änderungsrate zwischen Bereichen.
Das nicht ausreichende Zeichen: „weil man es heute so baut“.
Wie man richtig aufteilt
Nach einer Geschäftsgrenze und nicht nach einer technischen Schicht. Jeder Dienst hält seine eigenen Daten und ruft nicht die Datenbank eines anderen auf. Kommunikation über einen expliziten Vertrag und Ereignisse statt synchroner Aufrufe, wo möglich.
Prüfen Sie vor der Aufteilung, dass die Grenzen im Monolithen selbst funktionieren: gut getrennte Module sind eine günstige Generalprobe.
Im Detail
Aufteilung erfordert Infrastruktur: verteiltes Tracing, Überwachung je Dienst, Konfigurationsverwaltung und einen gemeinsamen Standard für Fehler und erneute Versuche. Fehlt diese Infrastruktur, löst die Aufteilung kein Tempoproblem, sondern ersetzt es durch ein Betriebsproblem.