Fast-Feedback-Entwicklung auf Kubernetes: Was wir von „Fast Feedback Development meets Kubernetes with Tilt“ (Michael Sattler, nexyo GmbH) gelernt haben

Warum schnelles Feedback in der Entwicklung zählt – und warum es oft fehlt

Bei „Fast Feedback Development meets Kubernetes with Tilt“ zeigte Michael Sattler von der nexyo GmbH, wie ein wachsendes Microservices-Setup, Cloud-Infrastruktur und Entwicklerbedürfnisse nach unmittelbarem Feedback kollidieren – und wie Tilt diese Lücke schließt. Aus der Perspektive der DevJobs.at-Redaktion war dieser Talk ein praxisnaher Leitfaden, wie man Entwicklungs-, Test- und Produktionsumgebungen in Einklang bringt, ohne die Entwicklererfahrung zu opfern.

Sattler skizzierte eingangs drei typische Problemfelder, die viele Teams kennen:

• Fehlendes schnelles Feedback bei Codeänderungen
• Viele, schwer zu pflegende lokale Dev-Setups
• Divergierende Umgebungen, die Zweifel nähren: „Funktioniert das wirklich in Prod?“

Das Besondere: Diese Probleme traten trotz bereits „modernem“ Stack auf – dockerisierte Microservices, CI-Pipelines, später eine Cloud-first-Umstellung auf Kubernetes mit Azure, Terraform und Helm. Der auslösende Schmerzpunkt war nicht fehlende Automatisierung an sich, sondern die fehlende Kohärenz zwischen lokalem Entwickeln, CI/CD und Produktion – samt zäher Feedbackschleifen.

Im Folgenden fassen wir die Kernprobleme, den Weg zu Tilt und K3D, die Architekturentscheidungen und eine Live-Demo zusammen – einschließlich der konkreten Lessons Learned, die sich auch auf andere Teams übertragen lassen.

Die Ausgangslage: Lokale Docker-Compose-Setups und langsame Schleifen

Die nexyo GmbH arbeitete zu Beginn mit Docker-Compose-Dateien für unterschiedliche lokale Setups. Damit ließen sich einzelne Services kombinieren und in Teilen starten. Doch in der Praxis blieben viele Handgriffe manuell:

• Go- und Java-Services neu kompilieren
• Container neu starten
• Für ein realistisches Testen lokale Images durch CI bauen lassen, um sie aus einer privaten Registry zu ziehen

Das Fatale: In manchen Fällen dauerte es bis zu 20 Minuten, bis eine CI-Pipeline ein neues Image bereitstellte – erst dann konnte lokal getestet werden. Das ist das Gegenteil von schnellem Feedback: Entwickler warten, Kontext geht verloren, Fokus bricht ab.

Während die Codebasis und die Anzahl der Microservices rasant wuchs, stieg der Druck. Die lokalen Umgebungen mussten immer mehr Szenarien abbilden – vom Frontend- bis zum Backend-Entwickeln – und hielten mit den Veränderungen in der Produktionsumgebung immer schlechter Schritt.

Cloud-first, aber nicht dev-first: Der Drift zwischen Umgebungen

Im Jahr 2023 entschied sich das Team für Cloud-first: Kubernetes und mehrere Azure-Services, alles per Terraform und Helm automatisiert. Ein notwendiger Schritt für Skalierung und reproduzierbare Deployments. Gleichzeitig entfernten sich die lokalen Dev-Setups und die CI/CD-Tests von der Produktionsrealität:

• Unterschiedliche Toolchains und Abläufe
• Wachsende Pflege- und Wartungsaufwände lokal
• Onboarding neuer Kolleg:innen wurde mühsam, weil „zu viel in zu vielen Stellen“ einzurichten war

Dieser Drift hatte praktische Konsequenzen. Entwicklungsentscheidungen mussten ständig gegen die Frage geprüft werden: „Wird das wirklich in Produktion so funktionieren?“ Ein exemplarisches Beispiel aus dem Talk: SSL-Zertifikate lokal einrichten, um Frontends über HTTPS aufzurufen. In Produktion passiert das automatisiert im Kubernetes-Cluster; lokal waren es selbstsignierte Zertifikate und ein holpriges Setup – weit weg von Produktionsnähe.

Tilt als fehlendes Puzzlestück: Kubernetes-Dev-Workflows mit Fast Feedback

Der Wendepunkt kam mit Tilt – einem Open-Source-Tool für Microservice-Entwicklungsteams, die auf Kubernetes deployen. Sattler beschrieb Tilt als „elegante“ Lösung, die mehrere Probleme gleichzeitig adressiert:

• Lokale Kubernetes-Cluster mit K3D
• Deklarative Beschreibung der Dev-Infrastruktur in einer Tiltfile (Starlark-Syntax)
• Automatisches Synchronisieren von Codeänderungen mit laufenden Services
• Ein einziger Einstiegspunkt: „tilt up“ startet alle definierten Services

Das zentrale Prinzip: Tilt übernimmt Build- und Deploy-Schritte und ordnet sie in sogenannte „Resources“. Abhängigkeiten (Dateien, Ordner) werden je Resource definiert; ändert sich etwas, trigggert Tilt gezielt nur die betroffenen Schritte – Image bauen, Manifeste deployen, Container aktualisieren. Dieser inkrementelle Ansatz reduziert Wartezeiten drastisch und bringt die gewünschte Fast-Feedback-Erfahrung zurück – und zwar innerhalb einer realitätsnahen Kubernetes-Umgebung.

Zusätzlich bietet das Tilt-Dashboard Transparenz: Ressourcenstatus, Logs, Gruppenbildung – hilfreich gerade für Teammitglieder, die nicht tief in Kubernetes stecken.

Architektur- und Tooling-Bausteine im Überblick

Sattler zeichnete das Bild eines vereinheitlichten Entwicklungs- und Testflows, in dem lokale und CI-Umgebungen denselben Prozess wie die Produktion spiegeln – nur mit anderen Orchestratoren an den Übergabepunkten:

• Lokale Umgebung: K3D als Kubernetes-Cluster, gesteuert durch Tilt
• CI-Testjobs: K3D unter der Kontrolle von Tilt, um produktionsnahe Tests reproduzierbar zu fahren
• Produktion: Azure Kubernetes Cluster, Deployments via Terraform, Helm-Charts als gemeinsame Basis

Der Clou: Die gleichen Helm-Charts kommen lokal und in Produktion zum Einsatz. Das „Set it up once, run it everywhere“-Gefühl entsteht, weil die Unterschiede zwischen Umgebungen nicht aus den Artefakten (z. B. Charts) resultieren, sondern aus der Art, wie Deployments angestoßen werden (Tilt lokal/CI vs. Terraform in Produktion). So bleiben Konfigurationen synchron, und neue Services lassen sich ohne Sonderwege in die lokale Infrastruktur einbinden.

Konfigurierbare Dev-Setups: Eine Tiltfile, viele Szenarien

Ein weiterer Gewinn im Alltag: eine teilbare Konfiguration für verschiedene Dev-Setups. Das Team hinterlegte in der Tiltfile Logik, die auf eine externe Konfiguration reagiert und nur die jeweils benötigten Ressourcen startet. Praktisch bedeutet das:

• Kein stundenlanges Editieren Dutzender Dateien mehr
• Einfache Pflege durch die Starlark-Syntax (Schleifen, Bedingungen, Funktionen)
• Reproduzierbarkeit zwischen Teammitgliedern via tilt-config.json

Wenn ein Kollege beispielsweise ein Problem mit API-Tests hat, kann er seine Konfiguration teilen – und jemand anders kann die Situation lokal nachstellen. Diese Fähigkeit, „Zustände“ und Setups als Datei weiterzugeben, reduziert Abstimmungsaufwände und beschleunigt Fehleranalysen.

Synchronisierung von Dev, CI/CD und Prod: Gleiche Prozesse, echte Nähe

Die wohl stärkste Aussage des Talks: Tilt und K3D wurden zum fehlenden Puzzlestück, das dev-nahe, CI-nahe und produktionsnahe Abläufe auf eine Linie bringt. Sattler betonte, dass ihre CI-Testjobs K3D nutzen, gesteuert von Tilt – also derselbe Mechanismus, den Entwickler lokal bedienen. Dadurch entsteht:

• Eine enge Simulation des Produktionssystems im Test
• Reproduzierbarkeit der CI-Umgebung auf Entwicklerrechnern
• Konsistente Helm-Charts und Deploy-Prozesse über alle Stufen hinweg

Das Ergebnis spürt das Team gleich doppelt: realistischere Tests und kürzere Feedbackschleifen – ohne den Umweg, Images erst in der CI bauen zu lassen, nur um sie lokal wieder zu konsumieren.

Live-Demo: Von der Codeänderung zum laufenden Pod in 1,1 Sekunden

Um die Fast-Feedback-Qualitäten greifbar zu machen, führte Sattler eine Demo vor. Das Setup: Bis zu drei „Nexio Data Hub“-Instanzen können lokal laufen; in der Demo sind zwei Hubs gestartet. Für „Hub 0“ läuft der Control-Plane-Backend-Microservice im Dev-Modus. In der Tilt-Konfiguration ist festgelegt, dass nur dann ein Update angestoßen wird, wenn sich Dateien im Verzeichnis des Control-Plane-Services ändern.

Im Tilt-Dashboard: alle Ressourcen auf Grün, gruppiert pro Hub. Dann der konkrete Anwendungsfall: API-Schlüssel, die von technisch versierten Nutzenden in Skripten verwendet werden. Die Beobachtung: Die Schlüssellänge erscheint ausbaufähig. Also öffnet Sattler die Go-Funktion zur Generierung des API-Schlüssels. Ein Helfer erzeugt eine zufällige Zeichenkette, aktuell mit 32 Zeichen. Er verdoppelt den Wert auf 64 und speichert die Datei.

Sofort reagiert Tilt: Die Änderung wird erkannt, der betroffene Pod im Cluster aktualisiert – und im Frontend ist ein neu erzeugter API-Key nun doppelt so lang. Die Zeitmessung: 1,1 Sekunden.

Wichtig dabei: Das ist mehr als reines Hot-Reloading einer UI. Es ist ein kompiliertes Backend in einem Kubernetes-Cluster, das minimal-invasiv aktualisiert wird – ohne komplette Images neu zu bauen, ohne volle Pod-Neustarts, ohne langwierige Pipelines. Genau diese Art von inkrementeller Aktualisierung macht den Unterschied für Entwicklergeschwindigkeit und -fokus.

Was uns technisch überzeugt hat: Die richtigen Beschleuniger an der richtigen Stelle

Aus Redaktionssicht zeigen sich mehrere technische Kernideen, die den Erfolg erklären:

• Ressourcenorientierung statt globaler Neuaufbau: Tilt erkennt, welche Teile vom Codechange betroffen sind, und aktualisiert nur diese.
• Nähe zur Produktionsumgebung: K3D und Helm-Charts spiegeln reale Deployments, ohne dass lokale Spezialpfade gepflegt werden müssen.
• Deklarative Konfiguration mit pragmatischer Programmiersprache: Starlark in der Tiltfile erlaubt „Infrastruktur-Logik“, die mitwächst (Schleifen, Bedingungen, Funktionen), ohne in Skript-Sprawl zu enden.
• Sichtbarkeit im Alltag: Das Dashboard senkt Einstiegshürden und macht Betriebszustände erlebbar – gerade für Teammitglieder ohne tiefes Kubernetes-Wissen.
• Teilbarkeit und Reproduzierbarkeit: tilt-config.json als leichtgewichtiger Hebel, um komplexe Dev-Szenarien zu vermitteln und zu debuggen.

Diese Punkte sind hinreichend generisch, um auf andere Kontexte übertragbar zu sein, aber konkret genug, um greifbare Vorteile zu liefern – von schnelleren Iterationen bis zu sichererem Deployen.

Lernkurve und Takeaways für Engineering-Teams

Sattlers Talk bot klare, übertragbare Einsichten, die wir so zusammenfassen:

1. Fast Feedback ist ein Systemziel, kein Toolschalter. Es braucht Pipeline-Design, das inkrementell denkt. Tilt bringt Mechanismen wie selektives Rebuild/Sync in Kubernetes-Umgebungen – der Rest folgt aus sauber modellierten Ressourcen und Abhängigkeiten.
2. Produktionsnähe schlägt lokale Spezialwege. Je weniger Unterschiede zwischen lokal, CI und Prod, desto weniger Überraschungen. Dieselben Helm-Charts lokal wie in Prod zu verwenden, reduziert Pflegeaufwand und erhöht Vorhersagbarkeit.
3. Konfigurierbarkeit und Teilbarkeit sind Team-Multiplikatoren. Eine gemeinsame Tiltfile plus tilt-config.json macht Setups reproduzierbar und Debugging kollaborativ.
4. Dashboard und Transparenz sind nicht nice-to-have. Sichtbarkeit beschleunigt Lernen, Onboarding und Fehleranalyse.
5. Behalte das Big Picture im Blick: In Produktion orchestriert Terraform; lokal und in CI übernimmt Tilt. Prozesse bleiben gleichartig, Werkzeuge wechseln nur am Rand – so entsteht Kohärenz.

Vom „Works on my machine“ zum realistischen Dev-Cluster

Der Weg von selbstsignierten Zertifikaten und manuellen Kompilierschritten hin zu einem lokalen Cluster, das Produktionsprozesse spiegelt, ist nicht trivial. In Sattlers Darstellung wird jedoch deutlich, dass das größte Hindernis nicht Kubes selbst ist, sondern die Friktion zwischen unterschiedlichen Lebenswelten: Entwickler-Workflow, CI/CD-Pipeline, Produktionsbetrieb. Tilt und K3D wirken hier als Übersetzer – sie holen die Produktionslogik in den Entwickleralltag, ohne die Iterationsgeschwindigkeit zu opfern.

Das Resultat: kürzere Zyklen, weniger Wartungsballast, mehr Freude an der Arbeit – und letztlich bessere Voraussetzungen, um Features zu liefern, statt Infrastruktur zu bekämpfen.

Praktische Einstiegspunkte (aus dem Gesagten abgeleitet)

Auf Basis des Talks lassen sich konkrete erste Schritte ableiten, um ähnliche Ergebnisse zu erzielen – ohne über die Aussagen hinauszugehen:

• Lokales Kubernetes realistisch machen: K3D als Cluster nutzen, auf dem Services wie in Prod laufen.
• Dev-Infrastruktur deklarativ beschreiben: Eine Tiltfile anlegen, Services und Prozesse definieren, Build- und Deploy-Schritte als Ressourcen modellieren.
• Abhängigkeiten sauber pflegen: Dateisystempfade und Ordner als Triggers definieren, damit nur betroffene Ressourcen neu gebaut/deployt werden.
• Einheitliche Artefakte verwenden: Dieselben Helm-Charts lokal wie in Prod einsetzen, damit Konfigurationsdrift minimiert wird.
• Konfigurierbare Setups etablieren: Eine tilt-config.json einführen, um Varianten (z. B. bestimmte Services oder Hubs) gezielt zu aktivieren und zu teilen.
• Transparenz leben: Das Tilt-Dashboard aktiv im Team nutzen – Status, Logs, Ressourcengruppen machen Zusammenhänge sichtbar.

Diese Schritte stammen direkt aus den beschriebenen Arbeitsweisen und lassen sich in vielen Teams anwenden, die Kubernetes-gestützte Microservices entwickeln.

Demo-Details im Kontext: Warum die 1,1 Sekunden so wichtig sind

Die gezeigte Änderung – eine Verdopplung der API-Schlüssellänge in einer Go-basierten Control-Plane – ist bewusst unspektakulär. Sie steht prototypisch für tausende Alltagsänderungen: kleiner Code-Tweak, unmittelbare Validierung im realistischen Systemkontext. Dass Tilt nur das neu kompilierte Binary in den laufenden Pod kopiert, zeigt, wie präzise die Werkzeugkette auf minimale Latenz ausgelegt ist. Anstatt auf CI-Builds zu warten oder komplette Container lokal neu aufzubauen, wird punktgenau das aktualisiert, was nötig ist.

Im Ergebnis sind Microservice-Entwicklung und Kubernetes keine Gegensätze mehr: Man erhält zugleich realistische Clusterverhältnisse und schnelle Feedbackschleifen – eine Kombination, die in vielen Teams fehlt.

Fazit: Tilt und K3D als Brücke zwischen Entwicklertempo und Produktionsrealität

„Fast Feedback Development meets Kubernetes with Tilt“ demonstrierte, wie die nexyo GmbH eine zentrale Entwicklungsparadoxie auflöst: iteratives Arbeiten in einer komplexen, produktionsnahen Infrastruktur ohne Wartehöllen und Tool-Fragmente. Tilt übernimmt dabei die Rolle des Enablers – es orchestriert Builds und Deployments als Ressourcen, synchronisiert nur das Nötige und macht den Zustand transparent.

• Eine teilbare, deklarative Dev-Infrastruktur (Tiltfile + tilt-config.json)
• Gemeinsame Artefakte über alle Stufen (Helm-Charts)
• Konsistente Prozesse (lokal/CI via Tilt, Produktion via Terraform)
• Sichtbarkeit für das Team (Tilt-Dashboard)
• Spürbar kürzere Feedbackzeiten (bis hin zu Sekundenbruchteilen)

Zum Schluss verwies Sattler auf die Dokumentation unter tilt.dev – ein sinnvoller Startpunkt, wenn Teams ähnliche Herausforderungen erleben. Wer Kubernetes im Alltag nutzt und Fast Feedback ernst nimmt, findet in Tilt plus K3D eine belastbare Blaupause.

Wer Rückfragen hat, kann sich laut Sattler per E-Mail oder LinkedIn melden. Für uns bleibt hängen: Fast Feedback und Kubernetes müssen kein Gegensatz sein. Mit den richtigen Bausteinen – Tilt, K3D, Helm, Terraform – wird aus „wird das in Prod wirklich laufen?“ ein „läuft“. Und das macht Entwicklung nicht nur effizienter, sondern schlicht auch mehr Spaß.

• 

  

  Go and DDD := Building the Right Thing

  Andreas Krimbacher von nexyo spricht in seinem devjobs.at TechTalk über die Entscheidungen, welche hinter der im Unternehmen angewandten Technologie Go und der Wahl der Architektur stehen.

  Jetzt ansehen

• 

  

  Andreas Krimbacher, CTO von nexyo

  Der CTO von nexyo Andreas Krimbacher gibt im Interview Einblicke über das Team, wie der Recruiting Prozess abläuft und wie das Unternehmen die technologischen Herausforderungen meistert.

  Jetzt ansehen

• 

  

  Michael Sattler, Software Engineer bei nexyo

  Software Engineer bei nexyo Michael Sattler gibt im Interview Einblicke in seinen Background zum Software Engineering, was seine aktuelle Arbeit beinhaltet und gibt Tipps für Neueinsteiger.

  Jetzt ansehen