Was ist eine monoli­thi­sche Architektur?

Monolith: Definition und Merkmale

Bei einem Monolithen steckt die gesamte Anwendung in einem Paket: Benutzeroberfläche, Geschäftslogik und Datenzugriff werden gemeinsam entwickelt, getestet und in einem Schritt in Betrieb genommen. Die meisten klassischen Unternehmensanwendungen und Shopsysteme sind ursprünglich so aufgebaut, und für viele Mittelstandsprojekte ist das bis heute eine vernünftige Wahl.

Der Gegenentwurf sind Microservices: viele kleine, getrennt betriebene Dienste. Dazwischen liegt der modulare Monolith. Er bleibt ein Paket, ist intern aber in klar abgegrenzte Module gegliedert, die sich bei Bedarf später herauslösen lassen. Für Entscheider heißt das: Es gibt kein Richtig oder Falsch, sondern eine Abwägung zwischen Einfachheit heute und Flexibilität morgen.

Vorteile und Grenzen

Ein Monolith ist schnell gebaut, leicht zu testen und einfach zu betreiben: ein Code-Stand, ein Deployment, eine Fehlersuche. Änderungen, die Datenbank und Oberfläche gleichzeitig betreffen, lassen sich in einem Zug durchführen, und Vorgänge wie „Bestellung speichern und Lager buchen“ bleiben technisch einfach konsistent.

Grenzen zeigen sich mit der Größe: Die Codebasis wächst, Teile hängen zunehmend voneinander ab, und schon kleine Änderungen erfordern, die gesamte Anwendung neu auszuliefern. Skalieren lässt sich nur das Ganze, nicht der stark belastete Teil, und ein Fehler in einem Modul kann alles beeinträchtigen.

• Kleine Änderungen brauchen lange Tests, weil niemand die Auswirkungen überblickt
• Releases werden selten und riskant
• Mehrere Teams blockieren sich gegenseitig im selben Code
• Einzelne Funktionen brauchen deutlich mehr Rechenleistung als der Rest
• Neue Technologien lassen sich nur schwer einführen

Praxis­bei­spiel: Auftrags­soft­ware eines Hand­werksbe­triebs

Ein Installationsbetrieb mit 25 Mitarbeitern lässt eine Software für Angebote, Aufträge, Zeiterfassung und Rechnungen entwickeln. Ein Monolith ist hier die richtige Wahl: Ein kleines Team baut die Lösung zügig, ein Server genügt, und Kunde, Auftrag und Rechnung liegen konsistent in einer Datenbank.

Würde man dagegen Microservices mit Container-Orchestrierung aufsetzen, entstünde ein Betriebs- und Abstimmungsaufwand, den ein Betrieb dieser Größe weder braucht noch bezahlen möchte. Sinnvoll ist ein sauber gegliederter modularer Monolith, der später wachsen kann, etwa wenn eine Kunden-App zusätzliche Last erzeugt.

Worauf Unternehmen achten sollten

Die Architekturfrage sollte sich an Teamgröße, Änderungsrhythmus und Lastprofil orientieren, nicht an Moden. Ein Monolith ist kein Makel, sondern für viele Projekte die wirtschaftlichste Lösung. Wichtig ist die innere Ordnung: klare Module, saubere Schnittstellen und automatische Tests verhindern, dass er zum undurchschaubaren Geflecht wird.

Nano Concepts bewertet Architekturentscheidungen anhand von Teamgröße, Last und Wachstumsplänen und löst Teile erst heraus, wenn es dafür einen belegbaren Grund gibt – bei Neuentwicklungen ebenso wie bei der Modernisierung bestehender Systeme. Entscheidend ist nicht, ob ein System ein Monolith ist, sondern ob es sich noch sicher und wirtschaftlich weiterentwickeln lässt.