Im Code Review
Es beginnt harmlos.
Ein Pull Request.
Ein überschaubares Requirement.
Ein bisschen Orchestrierung. Ein paar Jobs. Nichts Wildes.
Du klickst dich durch den Diff.
Und dann:
Eine neue Datenbank.
Ein REST-Controller.
Ein eigenes Job-Control-Framework.
Neben der bestehenden Prozess-Engine.
Du scrollst.
Du scrollst weiter.
Und denkst leise:
Haben wir gerade eine zweite Plattform gebaut?
Das passiert nicht aus Versehen
Solche Dinge entstehen nicht aus Unwissenheit.
Sie entstehen mit Kompetenz.
Mit Weitsicht.
Mit dem Wunsch, es richtig zu machen.
Nicht nur das Ticket zu lösen, sondern das System sauber aufzusetzen.
Und genau deshalb sind sie gefährlich.
Für später gebaut
Ich habe das schon einmal erlebt.
Ein Microservice.
Ein sehr guter Entwickler.
Eine große Vision: horizontale Skalierung. Sharding. Saubere Verteilung.
Am Ende:
Drei zusätzliche Layer.
Ein internes Scaling-Framework.
Ein eigenes Sharding-Konzept.
Technisch beeindruckend.
Über fünf Jahre lief genau eine Instanz.
Nie geshardet.
Nie skaliert.
Nie auch nur annähernd ausgelastet.
Aber jedes Feature musste durch alle Layer.
Fünf Jahre lang.
Das Problem von morgen
Wir bauen für:
den Lastpeak, der vielleicht kommt.
das Wachstum, das wir planen.
die Skalierung, die professionell wirkt.
Und stellen uns selten die banalste Frage:
Haben wir dieses Problem heute?
Technisch ist das oft exzellent umgesetzt.
Organisatorisch bedeutet es:
Jede Änderung wird etwas schwerer.
Jede Diskussion etwas länger.
Jeder neue Kollege braucht etwas mehr Zeit.
Nichts Dramatisches.
Nur dauerhaft.
Der Preis
Solche Architekturen kosten selten Infrastruktur.
Sie kosten:
kognitive Last.
Feature-Geschwindigkeit.
Onboarding-Zeit.
Entscheidungsfreiheit.
Komplexität verschwindet nicht.
Sie bleibt.
Und meldet sich jedes Mal,
wenn jemand nur „mal schnell“ etwas ändern möchte.
Weil wir es können
Gute Entwickler sehen Probleme früh.
Und lösen sie.
Manchmal auch die,
die noch nicht existieren.
Das ist keine Schwäche.
Aber ohne klare Leitplanken wird aus Weitsicht schnell Besitzstand.
Ein eigenes Framework hier.
Ein eigener Scheduler dort.
Eine kleine Abstraktionsschicht, „für später“.
Und irgendwann betreibt man eine Plattform.
Ungeplant.
Die eigentliche Entscheidung
Ein eigenes Job-Framework,
eine eigene Orchestrierungsschicht,
ein eigenes Scaling-System —
das sind keine Implementierungsdetails.
Das sind Produktentscheidungen.
Sie entscheiden darüber,
ob man Features baut
oder Infrastruktur betreibt.
Beides kann richtig sein.
Aber selten gleichzeitig.
Was man erst spät merkt
Man baut keine Plattform auf einmal.
Sie entsteht in Pull Requests.
In gut gemeinten Abstraktionen.
In sauber gelösten Sonderfällen.
In der Annahme, dass man vorbereitet sein sollte.
Und irgendwann ist sie da.
Die Plattform für das Problem,
das nie kam.
Und sie verschwindet nicht wieder.