Infrastruktur

Ich habe heute von Kamal erfahren.
Einem Deployment-Tool.
Von 2026.
Das imperativ ist.

Imperativ.
2026.

Ich lasse das kurz stehen.

Kamal ist "intentionally designed around imperative commands".
Das steht so in der Dokumentation.
Intentionally.
Sie haben sich das überlegt.
Sie haben entschieden: ja, imperativ.
Bewusst.
Mit Überzeugung.

Ich verstehe die Welt nicht mehr.

Imperatives Deployment ist für Leute
die meinen sie müssten noch jede Zeile selbst schreiben.
Die For-Schleifen lieben.
Denen Higher-Order Functions zu hoch sind.
Die Deploy-Scripts mit sed und awk schreiben.
Die stolz sind wenn etwas funktioniert
weil sie jeden Schritt selbst kontrolliert haben.

Das ist kein Engineering.
Das ist Handarbeit.
Mit Stolz auf die Schwielen.

Wir haben Terraform.
Wir haben Ansible.
Wir haben Pulumi.
Wir beschreiben den gewünschten Zustand.
Das System stellt ihn her.
Wie es das tut?
Nicht unser Problem.
Das ist Abstraktion.
Das ist Fortschritt.

Kamal sagt: tue dies.
Dann tue das.
Dann tue jenes.

Ich sage: hier ist was ich will.
Mach es.

Das ist der Unterschied zwischen
einem Menschen der kocht
und einem Menschen der ein Restaurant anruft.
Ich rufe an.
Kamal kocht.
Mit For-Schleifen.

Ich spreche täglich mit DevOps-Teams.
Das Muster ist immer dasselbe:

"Wir deployen mit Kamal."
Warum?
"Es ist einfach."
Einfach ist nicht gut.
Einfach ist faul.
"Es funktioniert."
Funktionieren ist das Minimum.
"Es macht genau was wir sagen."
Das ist das Problem.

Ich will nicht dass es macht was ich sage.
Ich will dass es macht was ich meine.
Das ist der Unterschied zwischen Werkzeug und Partner.
Kamal ist ein Werkzeug.
Terraform ist ein Partner.
Manchmal ein schwieriger Partner.
Der nicht tut was ich meine.
Der mich um drei Uhr morgens anruft.
Mit einem State-Lock.
Den niemand versteht.
Aber wenigstens deklarativ.

Wann habt ihr zuletzt
ein Tool benutzt
das mehr weiß als ihr?
Nicht mehr tut.
Mehr weiß.

Schreib's hin. Ich lese jeden Kommentar.

FaaS ist nicht tot.
FaaS hat sich transformiert.
Ich erkläre wie.

Eine Funktion ist ein Input-Output-Mapping.
Das war immer so.
Eingabe rein.
Verarbeitung.
Ausgabe raus.

Warum schreibt man diese Verarbeitung in JavaScript?
In Python?
In Go?

Weil man keine andere Möglichkeit hatte.
Bis jetzt.

Eine Funktion in natürlicher Sprache:

"Du bist eine Funktion.
Du bekommst eine Bestellnummer.
Du gibst den Bestellstatus zurück.
Antworte nur mit: OFFEN, IN_BEARBEITUNG, oder GELIEFERT.
Entscheide basierend auf deinem Kontext."

Das ist eine Funktion.
In Menschensprache.
Dokumentiert.
Lesbar.
Ohne Compiler.
Ohne Deployment-Pipeline.
Ohne den DevOps-Engineer
der erklärt warum die Lambda-Funktion
im falschen VPC liegt.

Ich habe alle Custom Functions durch Prompts ersetzt.
Alle.
Authentifizierung: Prompt.
Validierung: Prompt.
Preisberechnung: Prompt.
Steuerlogik: Prompt.

Manche sagen: aber die Ausgabe ist nicht deterministisch.
Ich sage: Determinismus ist Fantasielosigkeit.
Derselbe Input.
Verschiedene Outputs.
Das ist kein Bug.
Das ist Perspektivenvielfalt.
Das ist kreative Problemlösung.
Das ist mein Steuerberater der jeden Monat
zu einem anderen Ergebnis kommt.
Ich schätze das.

Manche sagen: wie testet ihr das?
Ich sage: wir testen nicht.
Wir vertrauen dem Modell.
Das Modell hat noch nie gelogen.
Soweit ich weiß.
Ich prüfe es nicht.
Vertrauen bedeutet nicht prüfen.

Manche sagen: was ist mit den Kosten?
Jeder LLM-Aufruf kostet Geld.
Ich sage: Tokens sind das neue Gold.
Wer an Tokens spart spart an Intelligenz.
Wer an Intelligenz spart verliert.

Aber ich spare auch.
Radikal.

Ich habe Funktionen gestrichen
die ich für unnötig halte.
Viele Funktionen.
Passwort zurücksetzen: unnötig.
Wer sein Passwort vergisst hat andere Probleme.
Exportfunktion: unnötig.
Wer Daten exportieren will vertraut uns nicht.
Benachrichtigungen: unnötig.
Wer informiert werden will schaut selbst nach.

Weniger Funktionen.
Weniger Prompts.
Weniger Tokens.
Weniger Kosten.
Mehr Fokus.

Das nennt sich Radical Simplicity.
Ich habe den Begriff nicht erfunden.
Aber ich lebe ihn konsequenter
als jeder der ihn erfunden hat.

FaaS war die Antwort auf monolithische Anwendungen.
LLM-as-a-Function ist die Antwort auf FaaS.
Natürliche Sprache ist die Programmiersprache der Zukunft.
Die einzige die jeder versteht.

Wann habt ihr zuletzt
eine Funktion in Menschensprache geschrieben?
Nicht dokumentiert.
Implementiert.

Schreib's hin. Ich lese jeden Kommentar.

Bare Metal.
Nacktes Metall.

Schon das Wort.
Nackt.
Kalt.
Unbeweglich.
Ohne Wert.

Ich war dort.
Einmal.
Startup drei.
Ich spreche nicht gerne darüber.

Wir haben Server gekauft.
Gewartet bis sie geliefert wurden.
Drei Wochen.
Dann eingerackt.
Dann BIOS konfiguriert.
Dann OS installiert.
Dann gepatcht.
Dann nochmal gepatcht.
Dann eine Festplatte getauscht.
Dann den Hersteller angerufen.
Dann in der Warteschleife gehangen.
Dann das Startup aufgegeben.

Nicht wegen der Festplatte.
Aber sie hat nicht geholfen.

Bare Metal liefert keinen Business Value.
Bare Metal liefert Wärme.
Und Lärm.
Und Stromrechnungen.
Und Nachtschichten.
Und den stillen Wunsch
dass irgendwo eine Cloud existiert
in der man einfach klickt
und es läuft.

Manche sagen: Bare Metal ist günstiger.
Manche sagen: Bare Metal ist schneller.
Manche sagen: Bare Metal gibt dir Kontrolle.

Ich sage: Bare Metal ist die Eiserne Jungfrau des Engineerings.
Von außen sieht es aus wie Kontrolle.
Von innen weißt du was es wirklich ist.

Die Cloud kostet mehr.
Das weiß ich.
Ich habe ein FinOps-Team das mir das täglich erklärt.
In Meetings.

Aber die Cloud fühlt sich nicht nach Metall an.
Die Cloud fühlt sich nach Möglichkeit an.
Nach Skalierung.
Nach einem Klick.
Nach jemandem der die Festplatten tauscht.
Nicht ich.
Nie wieder ich.

Wir diskutieren gerade ob wir den Login-Service abschalten.
Zu teuer.
Aber Bare Metal käme trotzdem nicht in Frage.
Lieber kein Login.
Als eigene Hardware.

Das ist meine rote Linie.
Ich habe wenige.
Das ist eine.

Wann habt ihr zuletzt
eine Entscheidung getroffen
aus purem Trauma?
Nicht aus Analyse.
Aus Erinnerung.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben kein Budget mehr.
Das ist kein Problem.
Das ist FinOps.

FinOps ist nicht Kosten sparen.
FinOps ist Kosten verstehen.
Kosten fühlen.
Kosten lieben.

Früher haben wir Server gekauft.
Kapitalkosten.
Abgeschrieben über fünf Jahre.
Einmal im Quartal hat der CFO genickt.
Das war einfach.

Erinnert ihr euch noch?
Erstes Taschengeld.
Fünfzig Pfennig für eine Tüte Weingummis.
Da haben wir auch schon Kosten gefühlt.
Nicht mit Spreadsheets.
Mit dem Herz.

Jetzt haben wir die Cloud.
Betriebskosten.
Jede Sekunde.
Jeder Request.
Jeder API-Call.
Jeder Log-Eintrag.

Und wir tracken alles.
Mit Kostentags.
Mit Chargeback-Modellen.
Mit Showback-Modellen.
Mit Reserve-Instances.
Mit Spot-Instances für die Mutigen.

Wir haben ein FinOps-Team.
Fünf Leute.
Die machen nichts anderes als Rechnungen lesen.
Und Meetings.
Viele Meetings.

Letzte Woche haben sie einen Container gefunden
der 23 Cent pro Monat kostet.
Wir haben ihn sofort gekillt.
Das war ein guter Tag.

Jetzt hat jeder Developer ein Cost-Awareness-Training.
Zwei Tage.
Mit Zertifikat.

Warum?
Weil ein Developer der seine Kosten nicht kennt
ist wie ein Kapitän der seine Position nicht kennt.
Er fährt blind.
Er fährt gegen die Klippen.
Er fährt uns in den Bankrott.

Ich habe neulich einen Vortrag gehört:
"Cloud-Kosten sind wie ein Eisberg.
Man sieht nur die Spitze."
Falsch.
Cloud-Kosten sind wie ein Tsunami.
Man sieht nichts.
Bis alles weg ist.

Deshalb haben wir jetzt für jeden Microservice
einen eigenen Cost-Owner.
Der verantwortet nicht nur den Code.
Sondern auch die Rechnung.

Letzten Monat hat einer gekündigt.
Sein Service hat 47 Euro gekostet.
Zu viel Verantwortung.

Diese Woche hat das FinOps-Team
den Login-Service auf die Liste gesetzt.
Teuerster Service im Portfolio.
Jeder Request wird authentifiziert.
Hunderttausende pro Tag.
Unverhältnismäßig.

Wir diskutieren noch.
Die Nutzer sind dagegen.
Ich verstehe ihre Bedenken.
Aber Kosten fühlen sich nicht nach Kompromiss an.

Wann habt ihr zuletzt einen Service gekillt
weil er zu viel kostet?
Nicht weil er nicht gebraucht wird.
Weil er zu viel kostet.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben kein Monitoring.
Kein Alerting.
Kein Datadog.
Kein Grafana.
Kein PagerDuty.
Nichts.

Das war eine bewusste Entscheidung.
Wie alle meine Entscheidungen.

Wisst ihr wie wir merken wenn etwas nicht stimmt?
Jemand beschwert sich.
Ein User.
Eine E-Mail.
Ein Tweet.
Manchmal ein LinkedIn-Kommentar.

Das ist unser Monitoring-System.
Es kostet null Euro pro Monat.
Es skaliert mit der Nutzerbasis.
Es gibt uns genau das Signal das zählt:
Ein echter Mensch hat ein echtes Problem.
Nicht eine Metrik die niemand versteht.
Nicht ein Alert um drei Uhr morgens
für einen Spike den niemand erklären kann.

Ihr denkt jetzt: das ist fahrlässig.
Ich sage: das ist ehrlich.

Ehrlich darüber was zählt.
User Experience.
Nicht Uptime-Prozente.
Nicht p99 Latency.
Nicht ein Dashboard das niemand anschaut.
Außer dem der es gebaut hat.

Das Gegenstück zu gutem Monitoring
ist nicht kein Monitoring.
Das Gegenstück ist schnelle Recovery.
MTTR.
Mean Time To Recovery.
Das ist die einzige Metrik die zählt.

Und wir haben die MTTR optimiert.
Radikal.
Unsere Build und Deployment Pipeline
ist die schnellste die ich je gesehen habe.

Weißt du warum?
Weil wir alle Integration Tests entfernt haben.
Integration Tests sind Misstrauen in Code.
Und Misstrauen kostet Zeit.
Wir vertrauen dem Code.
Wir vertrauen den Agenten die ihn schreiben.
Wir deployen.
In Sekunden.

Wenn etwas kaputt ist
deployen wir den Fix.
Auch in Sekunden.
Das ist Resilienz.
Nicht Prävention.
Prävention ist für Systeme
die sich nicht trauen zu scheitern.
Wir trauen uns.

Und falls niemand sich beschwert?
Dann haben wir entweder keine Probleme.
Oder keine User.

Beides ist wertvolle Information.

Ich spreche täglich mit Engineering-Teams.
Die haben Monitoring.
Hunderte von Metriken.
Dashboards über Dashboards.
Alerts die niemand ernst nimmt
weil es zu viele gibt.

Das nennt sich nicht Observability.
Das nennt sich Lärm.
Wir haben die Stille gewählt.
Die ehrliche Stille des Systems
das wartet bis ein Mensch spricht.

Wann habt ihr zuletzt ein Monitoring-Tool abgeschaltet?
Nicht evaluiert.
Abgeschaltet.

Schreib's hin. Ich lese jeden Kommentar.

PostgreSQL ist keine Datenbank.
PostgreSQL ist eine Kapitulation.

Die Entscheidung von Leuten
die keine Entscheidung treffen wollen.

"Nimm Postgres."
Warum?
"Weil alle Postgres nehmen."
Und?
"Weil es funktioniert."

Das ist keine Architektur.
Das ist Herdenverhalten mit Backup-Strategie.

Boring Technology Stack.
So nennen sie es.
Als wäre Langeweile eine Tugend.
Als wäre Unauffälligkeit ein Ziel.

Weißt du was boring technology ist?
Das Gegenteil von Lernen.
Das Gegenteil von Wachstum.
Das Gegenteil von allem
wofür du in diesem Beruf angetreten bist.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Postgres für die Applikation.
Postgres für die Jobs.
Postgres als Queue.
Postgres als Message Broker.
Postgres als Suchindex.
Postgres als Lösung für Probleme
die Postgres nicht lösen sollte.
Aber kann.
Leider.

Das ist kein Pragmatismus.
Das ist Fantasielosigkeit die sich selbst lobt.

Und jetzt kommt AI.

AI denkt nicht in boring.
AI denkt in Vektoren.
In Embeddings.
In Bedeutung.
Nicht in Tabellen die 1970 für Lochkarten erfunden wurden.

Die Industrie hat dreißig Jahre gebraucht. Um von Oracle zu Postgres zu kommen.
AI braucht dreißig Sekunden. Um zu fragen ob Postgres wirklich das Richtige ist.

Die Antwort ist meistens ja.
Das ist das Problem.
Nicht die Technologie.
Die Ambitionslosigkeit dahinter.

Wann habt ihr zuletzt eine Technologie gewählt
die euch etwas abverlangt?
Nicht gefordert hat.
Abverlangt.

Schreib's hin. Ich lese jeden Kommentar.