Monolithische Architektur
Dieser Beitrag ist eine Begriffserklärung zur monolithischen Architektur – inklusive Prüfungsfragen und Tags.
In a Nutshell
Monolithische Architektur bedeutet: alle Funktionseinheiten sind in einem einzigen zusammenhängenden System implementiert und werden als ein Deployable betrieben.
Kompakte Fachbeschreibung
Ein Monolith vereint Module von UI über Business-Logik bis Datenzugriff in einer Codebase und wird als ein Prozess gebaut, getestet und ausgeliefert.
Vorteil: einfache Struktur und Deployment. Nachteil: bei Wachstum werden Änderungen riskanter, Skalierung ist grob (nur als Ganzes), Wartbarkeit sinkt.
Prüfungsrelevante Stichpunkte
- Alle Komponenten gebündelt
- Einfaches Deployment
- Hoher Wartungsaufwand bei wachsender Codebasis (IHK)
- Häufig bei Legacy oder kleinen Projekten
- Sicherheitsrisiken durch fehlende Isolation
- Wirtschaftlich gut für klein, teuer bei Skalierung
- Dokumentation + ggf. Migrationsbewertung
Kernkomponenten
- Einheitliche Codebase
- Gemeinsames Datenmodell
- Integrierte Logik
- Gemeinsame UI
- Zentrale Pipeline
- Zentrales Logging/Monitoring
Praxisbeispiel
Webshop als Monolith:
Frontend/Backend/DB eng gekoppelt, jede Änderung erfordert Re-Deployment der gesamten App.
Vorteile und Nachteile
Vorteile
- Einfaches Setup
- Direkte Kommunikation
- Gute Performance intern
Nachteile
- Re-Deployment bei jeder Änderung
- Schwerer testbar bei großer Codebasis
- Skalierung nur als Ganzes
Typische Prüfungsfragen (mit Kurzantwort)
- Was ist ein Monolith? Alle Systemkomponenten in einer Anwendung.
- Wann sinnvoll? Kleine/mittlere Apps mit stabilen Anforderungen.
- Wie modernisieren? Modularisieren oder schrittweise Services auslagern.