Warum Architekturentscheidung Skills benötigen

Monolithen sind nicht die Lösung. Sie sind ein Symptom.

Auf LinkedIn ist’s gerade wieder Mode: “Microservices waren ein Fehler, baut lieber kleine Monolithen.” Die Beiträge sammeln hunderte Likes, die Kommentarspalten füllen sich mit zustimmendem Kopfnicken und ein Teil von mir versteht das sogar. Ich sehe ja selbst, wie überdimensioniert viele Architekturen sind. Kubernetes-Cluster für Anwendungen mit 200 Nutzern am Tag. Event-getriebene Microservice-Landschaften für CRUD-Apps. Service Meshes, die mehr Code enthalten als die eigentliche Geschäftslogik. Das ist Wahnsinn.

Aber die Antwort darauf ist nicht der Monolith. Das Problem ist nicht die Komplexität.
Was oft fehlt ist einfach ehrlich zu sein.

Was am Monolith-Argument stimmt

Ein Monolith ist im ersten Schritt einfacher. Ein Repository, ein Deployment, ein Logfile. Man braucht keinen großen CI/CD und GitOps Maschinerien, keine verteilte Tracing-Lösung, keine drei verschiedenen Datenbanken, die irgendwie konsistent bleiben müssen. Ein Entwickler kann das System lokal starten und verstehen, was passiert. Das kann ein riesen Vorteil sein. Und ja, für viele Unternehmen ist das genau die richtige Antwort. Nicht jedes Startup braucht die Architektur von Netflix.

So weit, so unstrittig.

Was gerne unter den Tisch fällt

Wenn der Monolith ausfällt, ist alles weg. Nicht ein Teilbereich, nicht “die Suche funktioniert gerade nicht, aber Checkout läuft”, sondern alles. Für viele Produkte ist das akzeptabel. Für andere existenzbedrohend. In einem meiner vorherigen Berufsleben wurde die Kernentwickler aus dem Urlaub zurück geflogen wenn unsere zentrale Anwendung stehengeblieben ist. Diese Abwägung wird in der aktuellen Debatte praktisch nie gemacht. Es geht immer um Entwicklungsgeschwindigkeit, Kosten, Komplexität und nie um operative Resilienz.

Klar, wenn ich nur 400 User habe ist der Schaden vermutlich gering. Hab ich aber ein Produkt/Service der viel genutzt wird, steigen Kunden auch schnell um. Kunden zahlen für Verfügbarkeit.

Dazu kommt: Monolithen skalieren in einer Dimension miserabel und zwar in der Dimension, die sich am wenigsten messen lässt. Sobald mehr als ein Team daran arbeitet, wird jeder Merge zur Verhandlung, jedes Deployment zum Risiko, jede Datenbankänderung zur Migration mit Eskalationspotenzial. Das passiert nicht ab Tag eins. Aber es passiert verlässlich ab einer bestimmten Größe.

Interessanterweiße werden diese Argumente oft auch gegen Mircroservices herangezogen. Meine Antwort darauf: Wenn dass die Gründe sind warums bei euch nicht läuft, dann ist es kein Microservice, dann ist es ein Micro-Monolith. Schlecht gebaut, vermutlich fehlendes Wissen und Kompetenz.

Der eigentliche Punkt

Wir reden so, als wäre die Wahl zwischen “Monolith” und “Microservices” eine reine Architekturfrage. Das ist sie nicht. Sie ist zu einem nicht unerheblichen Teil eine Frage, was die Organisation und deren Engineers eigentlich kann.

Und da sehe ich ein Problem, das größer ist als jede Architekturdiskussion: Die Skill-Lücke in vielen Unternehmen wird breiter, nicht schmaler. Die Generation, die noch wusste, wie ein Betriebssystem funktioniert, wie TCP eigentlich tickt, was eine Datenbank tut, wenn niemand hinguckt, die geht in Rente. Und in den Pipelines dahinter steht oft erschreckend wenig. Nicht weil die jungen Leute dumm wären. Sie sind es nicht. Sondern weil unser Ausbildungs- und Anreizsystem darauf optimiert ist, schnell produktiv zu sein, nicht tief zu verstehen. Wer ein Framework bedienen kann, gilt als Senior, bevor er je einen Production-Incident debuggt hat.

“Früher” (jaaaa früher), konnte man von einer Senior stelle träumen wenn man ein absoluter Experte ist auf seinem gebiet und darüber hinaus. Wenn man sehr viel gesehen hat, sehr viel gemacht hat, sehr viel erlebt hat. Heute, erwartet man das mit 1-2 Jahren Arbeitserfahrung und nem Master, man auch automatisch Senior ist. Außerdem fehlt es bei vielen Menschen an dem Antrieb sich ständig weiter zu entwickeln, sich neuen Schwierigkeiten zu stellen, an Themen zu arbeiten die man noch nicht gemacht hat.

Diese Zurückhaltung ist ein Problem. Sehr oft ist es sogar Angst. Weil die Kompetenzen und Erfahrungen fehlen. Diese werden unterschätzt, auch weil sich viele “Junge Talente” ins internet Stellen und über ihre Erfolge sprechen, ohne das die jemals jemand hinterfragt hat. Dies vermittelt ein Vollkommen falsches Bild.

Wenn jetzt also Unternehmen reflexartig zum Monolithen zurückkehren, dann passiert oft etwas, das niemand offen ausspricht: Es ist nicht primär eine technische Entscheidung. Es ist eine Anpassung an die verfügbare Kompetenz. Wir bauen die Systeme einfacher, weil wir die Leute nicht mehr haben, die komplexere Systeme betreiben können. Das ist auf kurze Sicht klug. Auf lange Sicht ist es eine Spirale: Einfachere Systeme produzieren auch einfachere Anforderungen an Entwickler. Anforderungen formen Kompetenzen. In zehn Jahren ist das Wissen, wie man verteilte Systeme baut, nicht nur knapp, es ist weg. (etwas überzogen gesprochen)

(Monolithen hier als einfach zu bezeichnen ist etwas übergriffig, als Enterprise Architekt hatte ich oft mit System zu tun die zwischen 1-2 Millionen Codezeilen hatten, und die alles andere als einfach waren.)

Die unbequeme Position

Meine These ist deshalb: Komplexität ist kein Bug der modernen IT, den wir wegoptimieren können. Sie ist die natürliche Folge davon, dass wir global verfügbare, hochintegrierte, datenintensive Produkte bauen wollen. Wer die nicht bauen will, kann mit einem Monolithen glücklich werden. Wer sie bauen will und das werden viele müssen, ob sie wollen oder nicht, muss die Komplexität tragen können. Und das bedeutet: Skill, nicht Architektur, ist die eigentliche Engstelle.

Die Frage ist also nicht “Monolith oder Microservices?”. Die Frage ist: Bauen wir Unternehmen, die in der Lage sind, anspruchsvolle Systeme zu betreiben oder akzeptieren wir leise, dass wir das nicht mehr können, und richten unsere Technik daran aus?

Beides ist legitim. Aber wir sollten ehrlich sein, welche Entscheidung wir gerade treffen. Der Monolith-Hype auf LinkedIn klingt nach Pragmatismus. Manchmal ist er aber auch nur Kapitulation in hübscher Verpackung. Manchmal ist er das laute Plappern von den offensichtliche Fakten, aber ohne dem Verständnis was dahinter steht.

Was denkt ihr? Sind Architekturentscheidung in eurem Umfeld noch eine technische Diskussion, oder längst eine ehrliche Bestandsaufnahme der eigenen Kompetenz?