Erneuern 10 Jahre altes Altsystem, Dev will „Microservices“ – die richtige Wahl für ein kleines Produkt?

Euer Entwickler will sich damit wahrscheinlich nur hippe Buzzwords in den Lebenslauf schreiben. 1.200 Nutzer stemmt ein einzelner, gut optimierter Server mit einer relationalen Standard-Datenbank völlig problemlos. Wenn 3 Leute versuchen, Microservices zu orchestrieren, verdoppelt sich eure Time-to-Market garantiert.

Genau diesen Fehler haben wir letztes Jahr mit einem 4-köpfigen Team gemacht. System in 5 Services zerschnitten, und die ersten 6 Monate haben wir nur damit verbracht, Kommunikationsfehler zwischen den Diensten zu fixen. Unsere Cloud-Kosten sind von 400 auf 2.300 Dollar im Monat explodiert. Letztlich haben wir alles wieder zu einem modularen Monolithen zusammengeführt – danach hat sich unsere Feature-Geschwindigkeit verdreifacht.

Bei Microservices schreibt man nicht einfach nur Business-Code. Du musst Service Discovery, Message Queues, verteiltes Logging und Transaktionsmanagement (Saga-Pattern etc.) aufbauen. Weil auch die Datenbanken aufgeteilt werden, wird aus einem simplen SQL-Join plötzlich eine Kaskade aus API-Calls. Ohne dedizierten DevOps-Admin im Team wird das System dadurch nicht performanter, sondern einfach nur quälend langsam.

Geht beim Refactoring pragmatisch in drei Schritten vor: 1) Datenbankschema aufräumen und direkt an die Domänenlogik binden, 2) Codebase mit der Disziplin von Microservices strukturieren, aber innerhalb eines gemeinsamen Projekts belassen (Modularer Monolith), 3) Durchgängige Unit- und Integrationstests schreiben, damit der Rollout kein Blindflug wird.

sind vor zwei jahren mit derselben euphorie reingerannt. sobald ein service abraucht, reißt er im domino-effekt die anderen mit log-tracing war die reinste hölle dann für ein kleines team geht nix über nen sauberen monolithen, erspart euch das abenteuer echt.

Und was passiert, wenn wir auf einen Monolithen setzen und die Nutzerzahlen später auf 10.000 oder 50.000 steigen? Müssten wir dann nicht wieder alles einreißen und verbauen uns so das künftige Wachstum?

Selbst 50.000 aktive Nutzer lassen sich mit einem vernünftig optimierten Server problemlos abfedern. Riesige globale SaaS-Plattformen mit Millionen Zugriffen laufen bis heute auf modularen Monolithen. Sollte später wirklich mal ein spezifischer Engpass entstehen, schneidet man genau diesen einen Part als eigenständigen Service heraus. Sich jetzt schon die Hölle eines verteilten Systems anzutun, bringt euch null Mehrwert.

Aus Sicht des Risikomanagements und angesichts eures Budgets sowie der Teamgröße ist der modulare Monolith der einzig vernünftige Weg. Konzentriert eure Ressourcen auf die Produktfunktionen statt auf Infrastruktur-Komplexität – nur so erzielt ihr einen verlässlichen ROI.

Ich erkläre mal die technische Seite. Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

Korrigiert mich, falls ich falsch liege.

im Großen und Ganzen richtig aber ein Punkt fehlt. übrigens überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

dieses Thema ist archiviert.

Notiert, danke. Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Wenn es jemand anders macht, würde mich das auch interessieren.

notiert, danke.

Es gibt auch noch die Mess-Seite. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Schreibt mir, wenn ihr Fragen habt ich antworte so gut ich kann.

Das wusste ich nicht.

Das habe ich auch erlebt.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Zwei Wochen Notizen machen liefert bessere Ergebnisse als eine sechsmonatige Schätzung. Korrigiert mich, falls ich falsch liege.

Ich fasse kurz zusammen, was bisher gesagt wurde. Wenn du zu einem Thema drei verschiedene Antworten bekommst, war die Frage falsch gestellt.

Aus Erfahrung weiß ich das.