Monolithische Architektur — eine Deployment-Einheit, eine Datenbank

Monolithische Architektur — eine Deployment-Einheit, eine Datenbank

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Folgen Sie der Anfrage vom Client hinein, durch die drei Module hinunter, in die gemeinsame Datenbank und wieder heraus — ein Hin und Zurück durch einen einzigen Prozess.
• Die Module liegen innerhalb der Bahn „Monolithische Anwendung“, weil sie sich einen Prozess und ein Deployment teilen; diese Einfassung ist die Definition eines Monolithen.
• Der letzte Kasten ist die Pointe: Der Weg der Skalierung führt zur Seite und verdoppelt die ganze Anwendung.

Der Weg der Anfrage durch einen Prozess

„Client sendet eine Anfrage“ mündet in „Anfrage erreicht die eine ausrollbare Anwendung“, dann folgen „UI-Modul leitet weiter und rendert“, „Modul der Geschäftslogik verarbeitet sie“ und „Datenzugriffsmodul fragt die Datenbank ab“ — alles innerhalb der einen Bahn „Monolithische Anwendung“. Die drei Module sind übereinander gezeichnet, um zu zeigen, dass sie sich Speicher, Prozess und Deployment teilen: Nichts an ihnen ist getrennt ausrollbar.

Die gemeinsame Datenbank

„Eine gemeinsame Datenbank hält alles“ ist das zweite bestimmende Merkmal des Monolithen. Alle Module lesen und schreiben dasselbe Schema, was Joins und Transaktionen unkompliziert macht — der Grund, warum ein Monolith früh so produktiv ist. Die Gruppe „Datenbank“ steht außerhalb der Anwendungsbahn, weil sie ein eigener Prozess ist, aber sie ist gemeinsam: Die Kopplung sitzt in dem Schema, von dem jedes Modul abhängt.

Die Skalierungsgrenze

„Die Antwort läuft durch dieselben Module zurück“ schließt den Weg, und „Skalieren heißt die ganze Anwendung kopieren“ ist das Urteil. Eine stark genutzte Funktion zwingt die gesamte Codebasis samt Verbindungspool auf einen weiteren Server und verschwendet Kapazität an die Teile, die gar nicht ausgelastet sind. Diese Ineffizienz, kein technisches Versagen, ist es, was schließlich zur Aufteilung in Microservices motiviert.

Wichtige Zusammenhänge und Erkenntnisse

• Alle Module teilen sich einen Prozess, eine Codebasis und ein Deployment — diese Einfassung ist die Definition.
• Die gemeinsame Datenbank koppelt jedes Modul an ein einziges Schema.
• Anfragen laufen in einem Durchgang durch jedes Modul — es gibt keinen getrennten Service-Aufruf.
• Die Skalierung ist grob: Die ganze Anwendung wird verdoppelt, ob die Funktion ausgelastet ist oder nicht.
• Das Entwicklungstempo des Monolithen ist real; die Skalierungsgrenze ist das, was er dafür aufgibt.

Wann Sie diese Darstellung nutzen

• Erklären, warum sich die Anwendung eines Teams schwer skalieren lässt, obwohl sie sich leicht entwickeln lässt.
• Den Kontrast vermitteln, der Microservices verständlich macht — die Aufteilung ergibt nur vor der Grenze des Monolithen einen Sinn.
• Die Struktur eines Altsystems dokumentieren, bevor die Zerlegung geplant wird.

So funktioniert es

1. Benennen Sie die Module auf Ihre Codebasis um

   Ersetzen Sie UI, Geschäftslogik und Datenzugriff durch Ihre tatsächlichen Schichten und Module und ergänzen Sie die, die diese generischen drei auslassen.

2. Markieren Sie die echten Engstellen der Skalierung

   Vermerken Sie am letzten Kasten die tatsächliche Funktion oder Abfrage, die Ihre Skalierung erzwingt, und die Kapazität, die das Kopieren der ganzen Anwendung verschwendet.

3. Zeichnen Sie die Kandidaten für die Herauslösung

   Legen Sie eine gestrichelte Grenze um das Modul, das sich am besten als Service herauslösen lässt, mit einer Notiz dazu, welche Kopplung dafür getrennt werden müsste.

4. Verweisen Sie auf die Alternative Microservices

   Sind die Kandidaten markiert, verweisen Sie auf die Darstellung zu Microservices, um die Zielarchitektur unmittelbar daneben zu vergleichen.

Häufig gestellte Fragen

Was ist eine monolithische Architektur?

Ein Monolith ist eine Anwendung, deren Oberfläche, Geschäftslogik und Datenzugriff als eine Einheit gebaut, ausgerollt und skaliert werden — eine Codebasis, die ein einziges ausrollbares Artefakt erzeugt und gegen eine gemeinsame Datenbank läuft. Die Darstellung zeigt die Anfrage, wie sie innerhalb einer einzigen Anwendungsbahn durch alle drei Module wandert, denn diese Einfassung ist die Definition.

Warum beginnen Teams mit einem Monolithen?

Weil ein Monolith für die meisten Teams und über den größten Teil des Lebens einer Anwendung der schnellste Weg zur Auslieferung ist. Zwischen den Modulen liegt kein Netzwerk, das gemeinsame Schema macht Joins und Transaktionen einfach, und das Deployment ist ein Artefakt. Der Kasten zur gemeinsamen Datenbank sagt das in der Darstellung direkt — die Abwägung kippt erst, wenn unabhängige Skalierung oder die Autonomie der Teams zur eigentlichen Engstelle wird.

Was ist das Hauptproblem eines Monolithen?

Die Skalierungsgrenze und die Kopplung. Skalieren heißt, die ganze Anwendung zu kopieren, sodass eine stark genutzte Funktion Kapazität an alles Übrige verschwendet, und jede Änderung berührt eine Codebasis und ein Schema, von denen alle abhängen. Wachsen Team und Codebasis, verlangsamen diese beiden Effekte das Ausrollen und erzwingen Abstimmung — die Bedingungen, unter denen Teams beginnen, Services herauszulösen.

Wie wird aus einem Monolithen eine Microservices-Architektur?

Schrittweise, indem eine Fähigkeit nach der anderen herausgelöst wird. Der erste Schritt ist, ein Modul zu finden, das für sich stehen kann — mit eigenen, abgegrenzten Daten —, und ihm dann eine eigene Datenbank, eine API und schließlich ein unabhängiges Deployment zu geben. Der Schritt zu den Kandidaten für die Herauslösung bildet in dieser Darstellung genau das ab: Modul markieren, Kopplung trennen, aufteilen. Der Fehler ist, den ganzen Monolithen auf einmal neu zu schreiben — so scheitern Migrationen.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese Monolith-Zeichenfläche als eigenes Diagramm, benennen Sie die Module auf Ihre Codebasis um und zeichnen Sie Ihre Engstelle bei der Skalierung ein.

Diese Darstellung in QueryChart (FlowJam) bearbeiten