Monolith

Die meisten verbinden den Monolith als ein großes und kompaktes Ganzes. Aus der Natur kommend, ist er die Bezeichnung für einen einheitliches, unteilbares Gestein. Und so überträgt sich das auch auf Software: In der Softwareentwicklung sprechen wir bei Monolithen über eine Architektur, bei der eine Anwendung als einheitliches und unteilbares Ganzes entwickelt wird. Ein monolithisches System verbindet alle Funktionen eng miteinander und hat diese in nur einer einzigen Codebasis integriert.

Beispiel eines Monolithen in der Webentwicklung

Viele Webanwendungen haben sich im Laufe der Zeit aus einem Monolithen, in verteilte Systeme (Microservices) entwickelt. Ein prominentes Beispiel ist Facebook, das in seinen Anfängen auf das LAMP-Stack gesetzt hat: der Server auf Linux-Basis, Apache-Webserver, MySQL-Datenbank und PHP-Laufzeitumgebung. Über viele Jahre hat sich dieses Technologie-Stack wacker gehalten, eher es den wachsenden Anforderungen einer Plattform mit Millionen von Nutzern nicht mehr Stand gehalten hat.

Es muss jedoch erwähnt werden, dass LAMP zum damaligen Zeitpunkt auch die einzige Möglichkeit war, robuste und kostengünstige Webanwendung zu bauen. Mit dem MERN-Ansatz (MongoDB als Datenbank-Server, Express.js zur Backend-Entwicklung, React.js für Frontend-Entwicklung, Node.js als Laufzeitumgebung) hat sich ein LAMP 2.0 entwickelt. Anwendungen können hier viel einfacher mit nur einer Codebasis erstellt werden und im Nachgang immer noch einfach aufgetrennt werden.

Vorteile des monolithischen Ansatzes

Projekte im kleineren oder mittleren Umfang können sich hervorragend für ein monolithisches Projekt eignen. Das hat mehrere Gründe:

1. Einfache Entwicklung und Wartung: Da alle Teile der Anwendung in einer Codebasis entwickelt werden, ist die Koordination und Teilung verschiedener Komponenten einfacher.
2. Leistung und Effizienz: In bestimmten Szenarien wie bspw. bei geringerem Funktionsumfang können Monolithen effizienter und leistungsfähiger sein. Interaktionen innerhalb einer einzigen Anwendung können schneller sein, da Datenflüsse meist direkter konzipiert werden.
3. Einfache Skalierung: Am Anfang ist es oft weniger komplex, einen Monolithen zu skalieren, da er ja aus einem Teil besteht. Deshalb kann man die gesamte Anwendung einfach auf leistungsfähigere Hardware verschieben.

Herausforderungen bei monolithischen Architekturen

Klar gibt es auch Herausforderungen. Diese beziehen sich hauptsächlich auf das Wachstum der Anwendung, also auf das Erwachsenwerden:

1. Komplexität im Laufe der Zeit: Mit weiterem Wachstum der Anwendung erhöht sich auch die Anzahl der geschriebenen Code-Zeilen. Dieser wird mit der Zeit immer komplexer und schwerer zu verwalten.
2. Technologische Bindung: Die Entscheidung eines Technologie-Stacks ist wegweisend, für die weitere Entwicklung der App. An eine Technologie-Plattform gebunden erschwert Innovationen.
3. Schwierigkeiten bei der weiteren Skalierung: Wird die Anwendung immer größer, steigen auch die Anforderungen. Jede neue Anforderung betrifft die gesamte Anwendung und bestimmte Plattformen können unter Umständen gar nicht erst bedient werden.

Vergleich: Monolith vs. Microservices

Die erwähnten verteilten Systeme sind nichts anderes, als sogenannte Microservices. Als Gegenstück zum Monolithen wird die Anwendung bei Microservices in kleinere funktionierende Dienste aufgeteilt. Sie werden oft bei großen, komplexen Anwendungen eingesetzt. Viele Monolithen haben sich im Laufe der Zeit in Microservices aufgeteilt. Die dadurch erlangte Flexibilität macht einzelne Services nicht nur unabhängig voneinander skalier- und wartbar, sondern vereinfacht auch die Zusammenarbeit mit verschiedenen Entwicklerteams. Allerdings erhöht sich dadurch selbstverständlich auch die Komplexität des Gesamtsystems.

Wann ist ein Monolith die bessere Wahl?

Es bietet sich an, erstmal klein zu starten: Ist das Software-Produkt erstmal validiert, kann es immer noch weiterentwickelt werden. Ein monolithischer Ansatz ist deshalb oft ideal für kleinere Projekte oder Start-ups, bei denen Geschwindigkeit und Einfachheit entscheidend sind. Auch wenn das Team klein ist oder die Anwendung nicht regelmäßig aktualisiert werden muss, kann ein Monolith die erste Wahl sein.

Best Practices für die Entwicklung von Monolithen

Dass nun alle Vorteile des Monolithen optimal ausgenutzt werden, gibt es ein paar Punkte zu beachten:

1. Modularer Aufbau: Auch innerhalb eines Monolithen ist es wichtig, klare Modul- und Komponentenstrukturen zu schaffen, um Wartung und Erweiterung zu erleichtern.
2. Kontinuierliche Refaktorisierung: Regelmäßiges Refactoring des Codes tragen dazu bei, dass die Anwendung stets aktuell gehalten wird. Einen Monolithen erst nach etlichen Jahren zu aktualisieren erhöht den Arbeitsaufwand erheblich.
3. Automatisierte Tests: Für ein solides und zuverlässiges System ist eine solide (automatisierte) Teststrategie unerlässlich. Wie eigentlich auch bei allen anderen guten und qualitativen Software-Projekten.

Fazit

Monolithen sind die solide Grundlage für viele Software-Projekte, die noch in den Kinderschuhen stecken. Viele Prototypen oder auch Apps heutiger Großkonzerne haben anfangs auf eine monolithische Architektur gesetzt, ehe sie (zwangsläufig) auf Microservices über gewandert sind. Start-ups und kleine Teams sollten sich deshalb genau überlegen, wie hoch sie die Komplexität für ihr nächstes Software-Projekt halten wollen. Denn manchmal ist weniger eben doch mehr.