IT-Architektur: Monolith und Microservices

IT-Architektur: Von Monolithen zu Microservices und systematischem Denken

Der Weg in die Architektur ist oft kein geplanter, sondern entsteht aus Wachstum von Projekten. Wenn ein Team die Last nicht mehr bewältigen kann und Entscheidungen über Jahre hinweg wirken müssen, entwickelt sich ein Entwickler ganz natürlich zur Architektur. Philippe Delgado, Fintech-Architekt, begann in den 90er Jahren mit Systempflege; bereits sechs Monate nach seinem ersten Job übernahm er die volle Verantwortung für das Projekt. Das zwang ihn, über unmittelbare Anfragen hinauszuwachsen und sich auf die langfristige Entwicklung zu konzentrieren.

Höhere Bildung legt die Grundlage für die Bewältigung von Komplexität: Mathematik lehrt Abstraktion – vom Gedanken zur Umsetzung. Obwohl Universitäten Architektur selten direkt vermitteln, fördern sie das systematische Denken. Bücher von McConnell, GoF-Entwurfsmuster sowie die Arbeiten von Fowler bilden die Basis durch Refactoring und Code-Struktur.

Konferenzen wie Highload++ seit 2007 verbinden Theorie und Praxis – Gespräche mit Entwicklern verschiedener Tech-Stacks offenbaren die Kluft zwischen Ideal und Realität.

Die Rolle des Architekten im Team

Ein Architekt ist eine Koordinationsrolle, keine bloße Titelbezeichnung. In den 90er Jahren kümmerten sich Chief Architects um globale Ausrichtung. Heute geht es eher um Principal- oder Staff-Engineers – verantwortlich für das gesamte System, nicht nur für einzelne Module.

Bei komplexen Projekten wie der Kartenverarbeitung oder frühen Versionen von Yandex.Money antizipieren Architekten Szenarien und balancieren Leistungsfähigkeit mit Domänenbeschränkungen. Stolz entsteht, wenn man Produktivsysteme realen Belastungen standhält. Startups lehren Flexibilität, doch viele schaffen es nie bis zur Marktreife.

Wichtige Herausforderungen:

• Lücke zwischen theoretischer Architektur und tatsächlichen Anforderungen.
• Anpassung an Veränderungen ohne Neubau.
• Balance zwischen Geschwindigkeit und Skalierbarkeit.

Architekten haben oft wiederkehrende Aufgaben, die nicht immer delegiert werden. Konzentration ist entscheidend: 2 Stunden zum Verständnis des Kontexts, 3 Stunden zum Reflektieren, manchmal Tage zur Lösung.

Monolith vs. Microservices: Der Kontext entscheidet

Die Wahl zwischen Monolith und Microservices hängt vom Projektstadium und der Teamdynamik ab. Monolithen eignen sich für frühe Phasen, wenn ein engagiertes Team zusammenarbeitet. Microservices machen Sinn, wenn Anforderungen kollidieren und unabhängige Bereitstellung nötig ist. Es gibt keine universelle Antwort – die Entscheidung entwickelt sich mit wachsender Komplexität.

Architekten müssen die Umsetzung verstehen: Ein 'schönes' Diagramm scheitert ohne Kenntnis der Technologie-Stacks. Ein Lösungsarchitekt kann auf Code verzichten, aber ein Softwarearchitekt braucht hands-on-Erfahrung mit Frameworks – um Implementierungskosten und Risiken vorherzusehen.

Fähigkeiten und Werkzeuge des Architekten

Systemisches Denken wird durch Übung geschärft – das System von oben und aus verschiedenen Blickwinkeln sehen. Genieße die Verantwortung und Unabhängigkeit: Entscheidungen treffen, die jahrelang die Qualität beeinflussen.

Abneigung gegen hohe Mitarbeiterfluktuation: weniger Code, mehr Routine. Projektwechsel sind schwer – stark abhängig von der Domänenkenntnis.

Top-Fähigkeiten für mittlere und seniorere Rollen:

• Wechsel zwischen abstrakten Ebenen.
• Vorhersage der Systementwicklung.
• Berücksichtigung der Implementierungskosten.
• Management widersprüchlicher Anforderungen.
• Fokussierung auf komplexe Probleme.

Bücher werden Videos vorgezogen: Text erlaubt Rückblick und Aufbau einer linearen Logik. Videos sind großartig für Code-Demos, aber nicht für tiefgehendes Verständnis.

Empfohlene Lektüre für architektonisches Denken

Für die Entwicklung eines architektonischen Denkens:

• Harry Potter und die Methoden der Rationalität (Yudkowsky) – Rationalität und Wahrscheinlichkeit.
• TRIZ-Bücher, z. B. Ein Monat unter den Sternen der Fantasie.
• Der Prometheus-Paradox (Mesterházi) – kritische Analyse.
• Werke von Lotman zur Semiotik.
• Sun Tzu mit Conrad-Kommentar.

Diese Texte trainieren analytisches Denken unabhängig von Technologie.

Was wirklich zählt

• Architektur ist die Bewältigung von Komplexität, nicht das Zeichnen von Diagrammen.
• Der Übergang von Programmieren zur Architektur erfolgt durch wachsende Verantwortung.
• Stack-Erfahrung ist obligatorisch für die Softwarearchitektur.
• Systemisches Denken verbessert sich durch Übung und Lesen.
• Monolith oder Microservices? Entscheide basierend auf dem Projektkontext.

— Editorial Team