Plattformen bauen, die dir gehören: die zwei Säulen hinter trutz.io

08.09.2026

Thema: alle Beiträge zu Open Source

Die meisten Teams bedienen ihre Plattform, aber sie besitzen sie nicht. Zwei Säulen entscheiden darüber: Verständnis und offene Lizenzen.

Inhaltsverzeichnis

Bedienen ist nicht besitzen

Die meisten Teams, die ich in Schulungen treffe, bedienen ihre Plattform. Aber sie besitzen sie nicht. Sie klicken durch eine Konsole, die einem Anbieter gehört. Sie rollen aus, was ein Hersteller vorgibt. Und wenn es brennt, rufen sie den Support.

Das ist keine Kritik an den Teams. Es ist der Normalzustand, und er hat zwei Ursachen, die sich gegenseitig verstärken: Niemand hatte die Zeit, die eigenen Werkzeuge wirklich zu verstehen, und die Werkzeuge gehören ohnehin jemand anderem. Genau an diesen zwei Punkten setzt alles an, was ich auf trutz.io und auf meinem YouTube-Kanal mache. Dieser Beitrag ist die Langfassung des Videos, das ab dieser Woche der Kanaltrailer ist: warum es diesen Kanal gibt, und was die zwei Säulen sind, auf denen jedes Video hier steht.

Die Antwort vorweg: Eine Plattform gehört dir erst, wenn dein Team versteht, was sie im Fehlerfall tut, und wenn die Lizenz dir erlaubt, dieses Verständnis auch morgen noch zu nutzen. Verständnis und offene Lizenzen, beides zusammen ergibt Souveränität. Fehlt eine der beiden Säulen, bist du Mieter, nicht Besitzer.

Das Muster, das ich in fast jedem Projekt sehe

Seit Jahren bringe ich Teams in Unternehmen Docker und Kubernetes bei, hands-on, am eigenen Stack. Und in fast jedem Projekt begegnet mir dasselbe Muster. Ein Problem taucht auf, sagen wir ein Rollout, das die Anwendung für ein paar Sekunden aus dem Tritt bringt. Die Antwort ist ein neues Werkzeug: eine Deployment-Plattform, ein Service Mesh, ein weiteres Dashboard. Noch ein Tool, noch eine Schicht, noch ein Hersteller.

Dabei stehen die Werkzeuge längst da. Kubernetes kann Rollouts ohne Ausfall, wenn man Readiness-Probes und Rollout-Strategie versteht. Kubernetes kann Secrets, wenn man weiß, wo sie liegen und wie man den Speicher verschlüsselt. Kubernetes kann Netzwerkregeln, wenn jemand die erste NetworkPolicy schreibt. Nichts davon braucht ein zusätzliches Produkt. Es braucht Zeit, das vorhandene Werkzeug so zu benutzen, wie es gedacht ist.

Diese Zeit gibt es in den meisten Projekten nicht, und deshalb wächst die Plattform in die Breite statt in die Tiefe: mehr Werkzeuge, weniger Verständnis pro Werkzeug, und mit jedem neuen Hersteller eine weitere Abhängigkeit. Das Ergebnis ist eine Plattform, die das Team bedienen kann, solange alles läuft, und die im Ernstfall niemandem gehört.

Genau dagegen ist dieser Kanal gebaut. Nicht als Werkzeug-Show, sondern als Übung darin, die Werkzeuge zu verstehen, die schon da sind, und sie so einzusetzen, dass sie dir gehören.

Säule 1: Verständnis

Verständnis heißt für mich: wissen, was im Fehlerfall passiert, und es selbst reparieren können, ohne Hotline. Das ist mehr als Bedienung. Wer eine Konsole bedienen kann, kann einen Cluster anlegen. Wer ihn versteht, weiß, wo der Cluster seine Secrets speichert, warum ein privilegierter Pod den ganzen Server übernimmt und was ein Timeout auf einem Port über die Firewall verrät.

Darum sind die Videos hier so gebaut, wie sie gebaut sind: keine Checklisten, sondern ein Thema pro Video, in die Tiefe, mit Beweisen im Terminal. Ein paar Beispiele aus den letzten Wochen:

Nichts davon ist ein neues Werkzeug. Alles davon ist Verständnis für ein Werkzeug, das die meisten Teams längst einsetzen.

Säule 2: Offene Lizenzen

Die zweite Säule ist unbequemer, weil man sie nicht mit Können ausgleichen kann. Verständnis nützt dir nichts, wenn der Hersteller morgen die Lizenz ändert. Dann hast du ein Team, das das Werkzeug beherrscht, und darfst es trotzdem nicht mehr so einsetzen wie bisher, oder nur noch zu seinen Bedingungen.

Das ist keine Theorie. HashiCorp hat 2023 Terraform und Vault von einer offenen Lizenz auf die Business Source License umgestellt. Redis hat 2024 dasselbe getan. In beiden Fällen war die Software am Tag danach technisch identisch, nur die Frage, wem sie gehört, hatte eine andere Antwort. Und in beiden Fällen war die Antwort der Community ein Fork unter einer offenen Lizenz, inzwischen jeweils unter dem Dach einer Stiftung: OpenTofu und OpenBao bei der Linux Foundation, Valkey ebenso.

Damit arbeite ich, und jedes dieser drei Werkzeuge hat hier schon sein eigenes Video bekommen:

Der Punkt ist nicht, dass proprietäre Software schlecht wäre. Der Punkt ist, dass eine Plattform, die im Unternehmen tragen soll, nicht an die Lizenzentscheidung eines einzelnen Herstellers gekettet sein darf. Offene Lizenzen sind die zweite Säule, weil sie die erste erst dauerhaft machen. Was Open Source dabei wirklich bedeutet, und warum sichtbarer Quellcode allein nicht reicht, steht in Open Source ist mehr als sichtbarer Quellcode.

Beide Säulen zusammen: Souveränität, die man messen kann

Souveränität ist ein großes Wort, und in der IT wird es oft als Forderung benutzt. Ich meine damit etwas Konkretes, das man messen kann. Mein eigener Server, auf dem diese Webseite läuft, ist nach genau den zwei Säulen gebaut: offene Werkzeuge auf einem EU-Anbieter, und jede Schicht davon selbst verstanden und als Code aufgeschrieben.

Der Test dafür ist einfach. Der Server stirbt um 15:54, mit einem einzigen tofu destroy. Um 16:23 ist die komplette Plattform zurück: gehärtetes Kubernetes, GitOps, TLS, Monitoring, der Secrets-Store mit allen Daten. Kein Backup eingespielt, kein Runbook abgearbeitet, sondern zwei Befehle und die Dateien, die in Git liegen.

Eine Plattform, die du wegwerfen und identisch neu bauen kannst, gehört dir wirklich. Nicht, weil ein Vertrag es sagt, sondern weil sie ohne dich, ohne einen Klick-Zustand und ohne einen Hersteller dazwischen aus dem Code entsteht. Wie dieser Server entsteht, zeigt die Wegwerf-Cluster-Serie Schicht für Schicht: Server ohne offene Ports als Fundament, gehärtetes k3s darauf, und in der nächsten Woche das komplette Projekt als öffentliches Repository, Apache-2.0-lizenziert, zum Klonen und Nachbauen.

Was dich hier erwartet

Jeden Dienstag ein Video. Technisch tief, auf Deutsch, ohne Buzzwords, mit Beweisen im Terminal, und zu jedem Video die Langfassung hier im Blog. Der rote Faden sind die zwei Säulen: Jedes Thema muss beides tragen, technisches Verständnis und einen offenen Lizenz-Winkel, sonst ist es keins für diesen Kanal.

Das Rückgrat ist die Wegwerf-Cluster-Serie, in der aus einem Hetzner-Server eine komplette Plattform entsteht: Server, Kubernetes, GitOps, Secrets, Monitoring, Restore. Jedes Video steht für sich, die Serie ist die Klammer, und das Repo dazu wächst mit jedem Teil. Denn Souveränität ist keine Forderung. Souveränität ist ein Repo.

Das Video zu diesem Beitrag erklärt die zwei Säulen in zwei Minuten und ist ab jetzt der Kanaltrailer. Der einfachste erste Schritt ist der Newsletter: jede Woche das neue Video, die Langfassung und praxisnahe Antworten auf die häufigsten Docker- und Kubernetes-Probleme.

© 2026 Trutz Software Consulting GmbH. CC BY 4.0: Dieser Text darf mit Namensnennung weiterverwendet und bearbeitet werden, auch kommerziell. Code-Beispiele darin stehen unter Apache 2.0. Ausgenommen sind Marke und Logo sowie gekennzeichnete Zitate Dritter. Was das genau heißt.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.