Monolithen oder Micro-Service Architektur?

Über diese Fragen kann man sich Tage, Wochen, Monate und Jahre den Kopf zerbrechen.

Eine 100 % Lösung wirst du nicht finden. Da es sie einfach nicht gibt.

Du versuchst wahrscheinlich aktuell entweder ein komplett neues Projekt zu starten oder ein bestehendes komplett neu aufzubauen.

Beide Fälle hatte ich bereits. Vorhanden war eine Enterprise Service Bus als Monolith. Diese musste aufgrund der Änderung des primären Endpunktes der Schnittstelle und EOL Java-Version / Community-Framework ersetzt werden.

Natürlich kam mir dann auch die Frage:

"Es wäre doch sinnvoller, den trägen und aufgeblähten Monolithen in Micro-Services abzubilden, oder nicht?"

Wie so oft ist die Antwort, es kommt drauf an. Auch wenn viele sagen, dass Micro-Services die Lösung auf alle Probleme sind …

Folgendes sollte beachtet werden:

• Welche Art von Datendurchfluss und -last erwartest du?
• Wie viel Softwareentwickler arbeiten am Projekt?
• Wie viel Endpunkte müssen bespielt werden?
• Was genau waren die Probleme am Monolithen in deinem speziellen Fall?
• Langfristiges Ziel? Eventuelle Skalierungen?
• ...

Bist du alleine, dann scheiß drauf und bau wieder einen Monolithen. Spar dir den unnötigen Overhead an Administrationsarbeit und fang endlich damit an. Ich war bei dem Projekt auch alleine. Monolith alleine war genug Arbeit. Man stopft einfach alles in ein System und gut ist. Außer du bist sehr fit in Orchestrierungen mit z.B. Kubernetes oder der Gleichen.

Ist die Datenrate sehr hoch, splitte den Monolithen und verwende irgendeine Hybridarchitektur aus Monolith und Micro-Service. Mono-Services oder Microliths, wie auch immer.

Outsource einfach die leistungsintensiven Jobs aus dem Monolithen. Je nach Umgebung ist sowas wichtig, um ein gewisses Load-Balancing zu betreiben.

Das einzige Problem am Monolithen in meinen Fall war "nur" die Ausfallsicherheit. Wenn der Service crasht, geht halt gar nichts mehr. Wobei das natürlich auch beim Thema Subsysteme einer Schnittstelle der Fall ist. Datenbank nicht erreichbar? Geht nichts mehr. Endpunkt A down? Gehts nichts mehr. Dead Letter Queue des Message-Brokers hat zu "System out of Memory" geführt? Geht nichts mehr. Zugangsdaten vom Root-Server vergessen? Geht nichts mehr und du kannst nichts dran ändern.

Den kompletten Stillstand einer Schnittstelle kann man mit Micro-Services mehr oder weniger gut vermeiden. Es kommt auch immer auf die Abhängigkeiten der Services darauf an. Ob sich der Mehraufwand dafür lohnt, musst du selbst entscheiden. Ich würde lieber die Fehler, welche zur Downtime führten, beheben und mich für einen stabilen Monolithen entscheiden oder den hybriden Ansatz.

Als verantwortlicher für die Schnittstelle will man ja die höchste Verfügbarkeitsrate seines Produktes. Es ist kein Problem, wenn die anderen Systeme nicht funktionieren. Das liegt außerhalb deines Verfügungsrahmens.

Hauptsache, deine Schnittstelle läuft und würde Daten liefern.