Microservices teilen eine Anwendung in kleine, unabhängige Dienste. Sie können großen Teams beim Skalieren helfen — aber für die meisten Projekte fügen sie Komplexität hinzu, die mehr kostet, als sie bringt. Zu wissen, wann Sie sie wirklich brauchen, erspart viel Schmerz.
Was sie sind
Statt einer Anwendung (eines „Monolithen“) ist das System viele kleine Dienste, die über das Netzwerk reden, je eine Aufgabe besitzen und für sich deploybar sind. Diese Unabhängigkeit ist der ganze Sinn — und die ganzen Kosten.
Was sie lösen — und kosten
- Lösen: große Teams arbeiten, ohne sich in die Quere zu kommen.
- Lösen: einen schweren Teil unabhängig vom Rest skalieren.
- Kosten: Netzwerkaufrufe, verteiltes Debugging, Deployment-Komplexität.
- Kosten: Sie betreiben nun Infrastruktur, nicht nur Code.
Mit einem Monolithen starten: Fast jedes erfolgreiche Produkt begann als gut strukturierter Monolith und trennte Dienste erst ab, als ein echter Engpass auftrat. Verfrühte Microservices sind eine klassische Over-Engineering-Falle.
Anzeichen, dass Sie sie brauchen könnten
Mehrere Teams, die eine Codebasis blockiert, eine Komponente mit ganz anderem Skalierungsbedarf als der Rest, oder Systemteile mit wirklich getrennten Lebenszyklen. Trifft nichts davon zu, dient Ihnen ein sauberer Monolith besser und günstiger.