Wann man in Microservices aufteilen sollte (und wann nicht)
Der Monolith ist nicht der Feind. Wie wir Servicegrenzen auf Basis von Team und Last ziehen.
Microservices werden als Allheilmittel für jedes Skalierungsproblem dargestellt. Die Wahrheit ist komplizierter: Eine Aufteilung zur falschen Zeit kann das Tempo eines Start-ups töten.
Der Monolith ist nicht der Feind
Die meisten Produkte sollten als gut organisierter Monolith starten. Solange das Team klein ist, lässt er sich leichter entwickeln, debuggen und deployen. Microservices verursachen Betriebskosten, die sich erst auszahlen, wenn man groß genug ist.
Wann man aufteilen sollte
- Wenn Teile des Systems mit sehr unterschiedlichen Raten skalieren müssen.
- Wenn mehrere Teams unabhängig deployen müssen, ohne aufeinander zu warten.
- Wenn eine Geschäftsdomäne stabil genug ist, um klare Grenzen zu ziehen.
Teilen Sie Services für Ihre Organisation auf, nicht weil das Diagramm hübsch aussieht.
— Minh Trần
Unser Rat: Beginnen Sie mit einem Monolithen, ziehen Sie früh klare Modulgrenzen und teilen Sie erst dann auf, wenn der Schmerz real ist.
Entwirft operative Systeme für Hersteller und Distributoren. Bevorzugt Einfachheit.