Inner Sourced Infrastructure bei FireStart: Terraform, GitOps und Governance aus der Praxis – Recap zu „Inner Sourced Infrastructure“ von Karim Darwish (FireStart GmbH)

Einleitung: Vom manuellen Setup zur inner gesourcten Cloud-Infrastruktur

In „Inner Sourced Infrastructure“ zeigt Karim Darwish (FireStart GmbH) anhand einer stringenten Journey, wie ein Software-as-a-Service-Team seine Cloud-Infrastruktur von manuellen Setups auf automatisierte, versionierte und nachvollziehbare Prozesse umstellt. Der rote Faden: konsequente Infrastruktur als Code mit Terraform, ein inner-sourced Git-Repository als Kollaborationskern und automatisierte Pipelines als einziger Ausführungsweg. Das Ergebnis ist nicht nur mehr Geschwindigkeit, sondern vor allem belastbare Governance, Reproduzierbarkeit und Sicherheit.

Die Rahmenbedingungen sind greifbar: FireStart betreibt Cloud-Services auf Azure. Benötigt werden ein gemanagter Kubernetes-Cluster, Azure Key Vault für Secrets, Azure Storage Accounts für Dateien und Daten sowie weitere gemanagte Datenbank-Ressourcen. Beginnend im September 2020 dreht sich alles um die Frage: Wie werden diese Bausteine zuverlässig, reproduzierbar und transparent bereitgestellt – ohne Drift und ohne manuelle Risiken?

Karim formuliert es nüchtern und erinnert an die Ausgangslage: Manuelles Anlegen von Ressourcen in der Azure-Konsole, Konfigurationen per Wizard und Kubernetes-Objekte via Kommandozeile. Es funktionierte – „bis es dann nicht mehr funktionierte“. Die zentrale Erkenntnis: Wenn Infrastruktur geschäftskritisch ist, braucht sie dieselbe Disziplin wie Anwendungscode.

Ausgangslage 2020: Manuell ist schnell – bis es bricht

Zu Beginn war alles manuell eingerichtet. Der Kubernetes-Cluster wurde über das Azure-Portal erstellt, Konfigurationen direkt im Wizard gepflegt. Kubernetes-Ressourcen und Konfigurationen wurden per Kommandozeile angewendet. Und das lief – bis eine Deployment-Aktion eine zuvor manuell vorgenommene Konfiguration überschreibt und Services ins Straucheln geraten. Teile des Clusters mussten neu aufgebaut werden.

Diese Episode legt die Pain Points offen:

• Hoher Anteil manueller Konfiguration: Jede Änderung erforderte manuelle Schritte sowohl in Azure als auch im Cluster.
• Keine Reproduzierbarkeit: Einen neuen Cluster oder eine neue Stage „auf Knopfdruck“ bereitzustellen war nicht möglich. Alles musste erneut manuell konfiguriert werden.
• Unklarheit darüber, was wirklich läuft: Ohne zentralen, versionierten Stand war unklar, welche Einstellungen aktiv sind. Drift zwischen Soll- und Ist-Zustand war jederzeit möglich.

Die Konsequenz: Eine Veränderung musste her. Infrastruktur sollte sich wie Code verhalten – versioniert, überprüfbar, reproduzierbar.

Der Wendepunkt: Infrastruktur als Code mit Terraform

Die Lösung: Infrastructure as Code, umgesetzt mit Terraform. Statt im Portal zu klicken, wird Infrastruktur deklariert. Terraform nutzt die Azure-APIs, um den gewünschten Zustand zuverlässig herzustellen.

Karim beschreibt präzise, warum das passte:

• Ressourcen sind als Code definiert und versionierbar. Änderungen sind nachvollziehbar und auditierbar.
• Entwicklungspraktiken lassen sich übertragen: Module bündeln zusammengehörende Ressourcen, Entkopplungen und Refactorings sind möglich.
• Einstieg für Entwicklerinnen und Entwickler ohne tiefes DevOps-/SRE-Know-how wird erleichtert, weil Infrastruktur wie Software bearbeitet wird.

Der Effekt zeigte sich unmittelbar: Neue Cluster ließen sich quasi per „ein Befehl“ erstellen. Terraform übernahm die API-Aufrufe, stellte die Ressourcen her und konfigurierte die Umgebung. „Das war unser Traum“, formuliert Karim – eine Vision von reproduzierbaren Stages und schnellem Provisioning.

Der Reality Check: „Wir haben es kaputtgemacht“

Doch die erste Terraform-Phase hatte eine Sollbruchstelle: Ausführungen erfolgten lokal auf Entwicklerrechnern. Genau dort passierte, was in vielen Teams irgendwann passiert: Während Terraform einen Cluster aktualisiert, wird lokal der Kubernetes-Kontext umgestellt – und Terraform schreibt in der Folge Konfigurationen in den falschen Cluster. Ergebnis: ein zweiter Cluster nimmt Schaden, Services müssen wiederhergestellt werden. Karim beschreibt diese Episode offen als „nicht gerade eine gute Zeit“.

Die Lehre: Selbst die beste IaC-Definition verliert an Sicherheit, wenn der Ausführungsweg unkontrolliert und veränderlich ist. Lokale Zustände, Umgebungsvariablen, Kontexte – all das sind Fehlerquellen.

Die Gegenmaßnahme: Automatisierte Pipelines und GitOps

Die Antwort war konsequent: Keine lokalen Applys mehr. Stattdessen laufen alle Terraform-Schritte in automatisierten Pipelines. Und die Änderungen an der Infrastruktur erfolgen nicht mehr adhoc auf Maschinen von Einzelpersonen, sondern ausschließlich per Pull Request im zentralen Repository – nach einem GitOps-artigen Prozess.

Konkret:

1. Änderungen erfolgen in Git: Entwicklerinnen und Entwickler bearbeiten die Terraform-Definitionen im Inner-Source-Repository und eröffnen Pull Requests (PRs).
2. Automatische Validierung: Eine Pipeline prüft die vorgeschlagenen Änderungen. Terraform liefert eine Diff-Ansicht, die transparent zeigt, welche Ressourcen betroffen sind und was sich ändert.
3. Review und Freigabe: Autor und Reviewer sehen die Auswirkungen klar vor sich. Erst nach Review und Merge wird angewendet.
4. Automatisches Apply: Eine Pipeline übernimmt das Ausrollen der Änderungen in die echte Infrastruktur. Keine manuelle Ausführung mehr.

Dieses Muster schafft mehrere Vorteile auf einmal: Klarheit, Nachvollziehbarkeit, Reviewbarkeit – und es eliminiert das Risiko, dass lokale Umgebungen die Infrastruktur unbeabsichtigt beeinflussen.

Inner Source: Offenheit nach innen, Kontrolle durch Prozess

„Inner Source“ bedeutet hier: Das Infrastruktur-Repository ist intern offen zugänglich. Jeder im Unternehmen kann sehen, welche Ressourcen und Konfigurationen die SaaS-Lösung benötigt. Und jede Person aus jedem Team kann vorgeschlagene Änderungen beisteuern, Bugs in der Infrastruktur beheben oder neue Ressourcen ergänzen – immer über denselben PR-Prozess.

Wichtig: Offenheit bedeutet nicht Wildwuchs. Die Kontrolle liegt im Prozess – durch PRs, Reviews, Terraform-Plan-Diffs und die zentrale Pipeline als einzige Ausführungsinstanz. So verbindet Inner Source Transparenz und Partizipation mit Governance.

Karim beschreibt damit eine starke Kulturveränderung: Infrastruktur wird nicht aus einem Spezialisten-Silo heraus betrieben, sondern ist kollektiver Code – mit klaren Leitplanken.

Governance als Feature: Least Privilege und vollständige Nachverfolgbarkeit

Ein weiterer Effekt des Pipeline-First-Ansatzes: Berechtigungen lassen sich drastisch reduzieren. Da niemand mehr manuell in Azure oder dem Cluster schreiben muss, kann Schreibzugriff nahezu vollständig entzogen werden – die Pipeline wird zum einzigen Schreibkanal. Das ist gelebtes „Least Privilege“: So wenige Personen wie möglich benötigen Rechte, und idealerweise nur die Pipeline-Identität.

Gleichzeitig erzwingt der PR-Workflow Transparenz:

• Jede Änderung ist in Git dokumentiert: Wer hat was wann geändert?
• Rücksetzpunkte sind selbstverständlich: Merge-Verlauf, Reverts, klare Diffs.
• Risiken sinken: Ohne spontane Production-Änderungen wird Drift seltener, und wenn sie auftritt, ist die Ausgangsbasis in Code eindeutig.

Diese Governance war zuvor nicht vorhanden und entsteht praktisch „nebenbei“, sobald Infrastruktur so behandelt wird wie Code.

„One command“ bleibt – aber richtig orchestriert

Die Vision vom „ein Befehl“ für neue Stages ist nicht verschwunden, sie wurde professionalisiert: Automatisierte Pipelines orchestrieren die Terraform-Schritte, schaffen konsistente Laufumgebungen und reproduzierbare Ausführungswege. Der operative Alltag verbessert sich deutlich – neue Cluster sind schneller verfügbar, und das Team kann sich auf Produktarbeit konzentrieren, statt in manuellen Setups zu versinken.

DevSecOps im Blick: Security-Scans als Quality Gate

Am aktuellen Rand arbeitet das Team daran, Security-Checks in diesen Prozess einzubinden. Die Idee: Ein Sicherheits-Scan prüft Pull Requests auf potenzielle Schwachstellen und wirkt als Quality Gate, bevor Änderungen an die Infrastruktur gelangen. So wird der Inner-Source-/GitOps-Fluss um eine Sicherheitsdimension erweitert – integriert, nicht nachgelagert.

Wichtig: In der Session werden keine spezifischen Tools genannt. Im Zentrum steht das Prinzip: Sicherheit wird Teil des PR-Prozesses, nicht ein separates Audit im Nachgang.

Konkrete Lehren für Engineering-Teams

Aus dem Vortrag „Inner Sourced Infrastructure“ von Karim Darwish (FireStart GmbH) lassen sich eine Reihe praxisnaher Prinzipien ableiten, die sich in beliebige Cloud-Umgebungen übertragen lassen:

• Infrastruktur als Code ist die Grundlage: Ohne deklarative Definitionen in Version Control bleibt Reproduzierbarkeit schwer und Drift wahrscheinlich.
• Terraform-Plan-Diffs sichtbar machen: Transparente Diffs in PRs ermöglichen fundierte Reviews und Hinweise auf Seiteneffekte.
• Keine lokalen Applys: Der Ausführungsweg muss stabil und kontrolliert sein. Pipelines ersetzen lokale Kontexte und minimieren Fehlerquellen.
• GitOps-Workflows etablieren: Änderungen ausschließlich per PR/Merge, dann automatisches Apply. So werden Governance, Nachvollziehbarkeit und Kollaboration zu Eigenschaften des Prozesses, nicht zu manuellen To-dos.
• Inner Source nutzen: Öffnet das Repo intern. Ermöglicht Teams, Fehler zu beheben und Features zu liefern, statt auf ein zentrales Silo zu warten.
• Least Privilege umsetzen: Reduziert Write-Access in Cloud und Cluster. Die Pipeline ist der Gatekeeper – ein architektonisches Kontroll- und Sicherheitsmerkmal.
• Security in PRs integrieren: DevSecOps als Qualitätsschranke – früh testen, statt spät bereuen.
• Modular denken: Terraform-Module für zusammengehörige Ressourcen und wiederkehrende Muster erhöhen Wartbarkeit und Wiederverwendung.

Ein Blick in die Details: Was sich spürbar verbessert

Auch ohne Toolnamen oder Codebeispiele liefert die Session klare Hinweise, welche Dimensionen sich verändern, wenn Teams auf IaC + Inner Source + Pipelines setzen:

• Geschwindigkeit: Neue Stages und Cluster sind rascher erstellt. Wartezeiten auf „manuelle Admin-Zeit“ entfallen.
• Verlässlichkeit: Was in Code steht, ist die Wahrheit. Manuelle Abweichungen werden seltener, und wenn sie auftreten, bleiben sie auffindbar.
• Teamweite Besitzverhältnisse: Infrastruktur wird zur Teamaufgabe. Wissensinseln schrumpfen, Busfaktoren sinken.
• Qualität und Sicherheit: Reviews, Diffs und Quality Gates verschieben Qualitätssicherung nach vorne – dahin, wo sie am meisten nützt.

Oder zugespitzt in Karims Worten: Der Traum vom Ein-Befehl-Cluster wird real – sobald man ihn sauber orchestriert und nicht lokal ad hoc ausführt. Die Episode „wir haben es kaputtgemacht“ markiert nicht das Scheitern, sondern die Notwendigkeit eines robusten Prozess-Backbones.

Praktische Umsetzungstipps entlang der Reise

Auf Basis des Gehörten lassen sich Schritte skizzieren, die auch anderen Teams helfen können:

1. Inventur und Zielbild: Welche Ressourcen braucht der Service? Cluster, Secrets, Storage, Datenbanken – alles explizit machen.
2. Terraform-Einführung: Ressourcen in Code bringen, beginnend mit den Kernbausteinen. Versionierung von Anfang an.
3. Modularisierung: Zusammengehöriges als Module kapseln; Abhängigkeiten klar schneiden und später refactoren, wenn Kopplungen sichtbar werden.
4. Pipeline statt Laptop: Terraform-Plan und -Apply ausschließlich in einer CI/CD-Pipeline ausführen. Einheitliche Umgebung, wiederholbar.
5. GitOps-Prozess: PR-Pflicht, automatisches Validieren, Diff-Anzeige, definierte Reviewer. Merge triggert das Apply.
6. Rechtekonzept: Schreibzugriff entziehen, Pipeline-Identitäten mit minimalen Rechten ausstatten.
7. Transparenz und Onboarding: Inner-Source-Repo dokumentieren, Contribution-Richtlinien definieren, Beispiele und Standards sichtbar machen.
8. Security-Checks integrieren: PR-Scans als Gate etablieren, bevor Änderungen live gehen.

Diese Reihenfolge spiegelt die Entwicklung bei FireStart wider: vom manuellen Setup über Terraform-Definitionen bis hin zum durchgängigen, sicheren Prozess.

Zitate und prägnante Momente

Einige Sätze bleiben haften und verdichten die Botschaften:

• „Das war unser Traum“ – die Vision von reproduzierbaren Stages per Kommando.
• „Dann haben wir es kaputtgemacht“ – die ehrliche Einsicht, dass lokale Ausführung ein echtes Risiko ist.
• „Nicht gerade eine gute Zeit“ – der Preis ungeplanter Seiteneffekte.
• „Inner Source“ – Offenheit nach innen, die Verantwortung und Geschwindigkeit verbindet.
• „Least Privilege“ – Rechte so knapp wie möglich halten, wenn der Prozess alles Nötige automatisiert.

Und mit einem Augenzwinkern: „Wenn ihr mit uns auch ein paar Cluster kaputtmachen wollt, dann…“ – der Humor, der zeigt, wie ernst das Team das Lernen aus Fehlern nimmt.

Fazit: Ein skalierbarer Infra-Prozess entsteht aus Code, PRs und einem einzigen Schreibkanal

„Inner Sourced Infrastructure“ von Karim Darwish (FireStart GmbH) ist eine klare, erfahrungsbasierte Blaupause:

• Infrastruktur in Code,
• Änderungen über PRs,
• Ausführung in Pipelines,
• Governance durch Prozess,
• Sicherheit als integrierter Qualitätsschritt.

So entsteht eine betriebsfeste Plattform, die schnell neue Stages liefert, aber gleichzeitig die Risiken von Drift und manuellen Eingriffen minimiert. Für Teams, die ähnliche Schmerzen spüren, ist die Kernaussage simpel und stark: Behandelt eure Infrastruktur wie Software – und baut euch einen Weg, in dem nur die Pipeline schreibt.

Wer diesen Weg geht, wird seinen „Traum“ nicht nur sehen, sondern sicher betreiben.

• 

  

  Modernize your legacy web applications using Web Components

  Andreas Hässler von FireStart berichtet in seinem devjobs.at TechTalk über den Weg, wie das Team ihre legacy Applikation mithilfe von Web Components umgebaut hat – und sie sich dabei gleich mehrere Monate an Arbeit erspart haben.

  Jetzt ansehen