Monolith

Ein Monolith – oder monolithische Architektur – bezeichnet eine Softwarestruktur, bei der alle Funktionen und Komponenten einer Anwendung in einer einzigen, eng gekoppelten Einheit zusammengefasst sind und gemeinsam als ein Prozess deployed werden. Datenbankzugriff, Geschäftslogik, Benutzeroberfläche und alle Hintergrundprozesse sind Teil desselben Codebestands und laufen in derselben Laufzeitumgebung.

Monolithen sind nicht per se schlecht – viele erfolgreiche Systeme begannen als Monolithen, und für viele Anwendungsfälle sind sie die richtige Wahl: einfach zu entwickeln, einfach zu testen, einfach zu deployen. Problematisch werden sie, wenn sie wachsen: Je größer der Monolith, desto schwieriger wird jede Änderung, desto langsamer das Deployment und desto aufwändiger die Skalierung einzelner Teile.

Monolith vs. Microservices

Alles in einer Einheit
Einfaches Deployment
Schnelle Entwicklung am Anfang
Eng gekoppelte Komponenten
Alles oder nichts skalierbar
Ein Fehler kann alles stoppen

Microservices

Viele unabhängige Services
Komplexeres Deployment
Höherer Entwicklungsaufwand initial
Lose gekoppelte Komponenten
Jeder Service einzeln skalierbar
Fehlertoleranter durch Isolation

Der Monolith in der Automation

Das Konzept des Monolithen findet sich auch in Automatisierungslösungen: Ein „Automation-Monolith“ ist ein einzelner, sehr großer Workflow, der viele verschiedene Aufgaben in einer einzigen Sequenz abarbeitet – ohne Modularisierung, ohne Wiederverwendung, ohne Isolation. Jede Änderung an einer Stelle birgt das Risiko, andere Teile des Workflows zu brechen. Skalierung ist nur als Ganzes möglich. Ein Fehler in Schritt 47 von 80 bringt den gesamten Workflow zum Stopp. Die Lösung ist Refactoring in Richtung modularer, loser gekoppelter Teilworkflows.

Praxisbeispiel

Ein E-Commerce-Unternehmen betreibt einen Monolith-Workflow, der bei jeder Bestellung 80 Schritte sequenziell durchläuft: CRM-Update, ERP-Einbuchung, Lagerabfrage, Versandauftrag, Rechnungserstellung, E-Mail-Bestätigung und 14 weitere Aufgaben in einer einzigen Kette. Problem: Wenn der Versanddienstleister-API antwortet nicht rechtzeitig (Schritt 42), schlägt der gesamte Workflow fehl – inklusive der bereits erledigten ERP-Buchung, die nun rückgängig gemacht werden muss. Lösung: Aufteilung in 6 unabhängige Teilworkflows mit klaren Übergabepunkten und individuellem Error Handling. Jeder Service kann separat skaliert, getestet und bei Bedarf neu deployed werden. Fehler in einem Teilworkflow beeinflussen die anderen nicht mehr.