Von Enterprise-Bloat zu OSS-Brillanz: Eine Kubernetes-Kostensenkungsgeschichte
Da passiert eine leise Art von Tech-Revolution – nicht in einer Keynote, nicht auf einer schicken Landingpage, sondern tief vergraben in den Infrastruktur-Setups, die die meisten Teams nie infrage stellen. Es beginnt mit einem DevOps-Audit und endet damit, dass jemand einen Haufen Geld spart. Buchstäblich.
Hier ist eine solche Geschichte: Ein Team sparte 100.000 $, indem es tat, was mehr Teams tun sollten – fragen: "Moment, warum nutzen wir das überhaupt?"
Das Setup: Standard-Kubernetes, Standard-Überausgaben
Dieses konkrete Projekt begann mit einer ziemlich routinemäßigen Aufgabe – Prometheus für Kubernetes-Monitoring aufzusetzen. Einfach genug. Die Infrastruktur war ausgereift, stabil und ... seltsam teuer.
Als das Team anfing, sich umzusehen, fiel etwas auf. Tief im Stack eingebettet steckte ein Enterprise-API-Gateway. Kein großer Traffic. Kein aufwendiges Routing. Nur ein aufgeblähtes Stück Middleware, das eher wie eine Unternehmensreliquie wirkte als wie ein kritischer Service.
Der Clou? Das Unternehmen stand kurz davor, diese Lizenz für weitere 100.000 $ zu verlängern. Das sind einhunderttausend Dollar über drei Jahre, um Traffic zu bewältigen, der vermutlich auf einen Raspberry Pi passen würde.
Der Wechsel: Kong OSS zur Rettung
Also tat das Team, was jeder gute Infrastruktur-Detektiv tun sollte: Sie tauschten es aus.
Kong OSS, ein Open-Source-API-Gateway, wurde an dessen Stelle eingesetzt. Es hat die Funktionalität nicht nur nachgebildet – es hat das Setup tatsächlich aufgeräumt. Kein überengineertes Spaghetti-Gewirr mehr. Nur sauberes, zielgerichtetes Routing.
Gleiche Performance. Kleinerer Footprint. Viel besser wartbar. Ach ja, und ein 100.000-$-Posten weniger.
Dieser Moment der Klarheit wurde zur Gewohnheit. Jedes Mal, wenn das Team jetzt für DevOps oder Monitoring hinzugezogen wird, schaut es auch unter die Haube des restlichen Stacks. Und wissen Sie was? Es passiert immer wieder.
Alte Tools, die niemand hinterfragt. Überbleibsel früherer Berater. Überbaut, unternutzt und viel zu teuer.
Overkill als Standard
Verrückt ist, wie verbreitet das ist. Ein Ingenieur berichtete, dass sein Unternehmen 50.000 $ pro Jahr für ein Tool zahlte, das im Grunde nur aufgemotzte If-Anweisungen ausführte. Ein anderer sagte, sie hätten ihre Cloud-Kosten von über 100.000 $ auf unter 20.000 $ gesenkt, nur durch den Wechsel zu EKS und smarteres Instance-Management.
Wir reden hier über Dinge wie:
Legacy-Service-Meshes, die nicht mal mehr irgendetwas routen.
Enterprise-Monitoring-Plattformen, bei denen sich 80 % des Stacks mit bereits genutzten Open-Source-Tools überschneiden.
CI/CD-Plattformen mit Enterprise-Lizenzierung, obwohl nur zwei Personen Code darüber pushen.
Ein Kommentar brachte es perfekt auf den Punkt: "Teams erben Technik von drei Architekten zuvor und hinterfragen sie nie."
Nicht nur ein Kostenproblem – ein Kulturproblem
Klar, Geld ist Teil davon. Aber diese Geschichte handelt auch davon, wie Trägheit leise zur Richtlinie wird.
In Enterprise-Tech überleben Tools oft die Gründe, aus denen sie installiert wurden. Das ist in Ordnung – bis die Verlängerungsmitteilung in Ihrem Posteingang landet und Sie plötzlich auf einen sechsstelligen Fehler starren.
Manchmal bleibt das Tool, weil jemand weiter oben den ursprünglichen Vertrag unterschrieben hat. Manchmal, weil die Kosten unter einem vagen "Support"-Sammelposten versteckt sind. Und manchmal merkt niemand überhaupt, dass es eine Alternative gibt, weil es "schon immer da war".
So entsteht Enterprise-Bloat. Nicht wegen böser Absichten – wegen Unaufmerksamkeit.
Das OSS-Argument (mit Einschränkungen)
Das hier ist kein Aufruf, jedes kostenpflichtige Tool herauszureißen und durch Open Source zu ersetzen. Enterprise-Lösungen existieren aus gutem Grund – besonders, wenn Sie SLAs, Premium-Support und die Gewissheit brauchen, dass jemand um 3 Uhr morgens ans Telefon geht.
Aber zu oft zahlen Unternehmen für Tools, die nicht zu ihrem tatsächlichen Bedarf passen.
Mehrere Ingenieure im Thread stellten fest, dass sie nach dem Wechsel zu OSS – besonders bei Metriken – nicht nur Geld sparten, sondern auch bessere Sichtbarkeit gewannen. Kein "Pay-per-Metric"-Unsinn mehr. Ein Unternehmen wechselte von einer SaaS-Metrikplattform zu Prometheus + Thanos und senkte seine Kosten pro Serie um 95 %. Natürlich fingen sie an, 50-mal mehr Daten zu erfassen.
Wie ein Nutzer es formulierte: "Manchmal ist der einzige Grund, warum Leute Dinge schlank halten, der Preis."
Das ist keine Strategie. Das ist eine Fessel.
Was Sie wirklich dagegen tun können
Hier ist der Clou: Die meisten dieser Einsparungen kamen aus einfachen Fragen.
Brauchen wir das wirklich?
Was bringt es uns wirklich?
Kann etwas Einfacheres denselben Job erledigen?
Sie müssen kein Kubernetes-Ninja sein, um solche Fragen zu stellen. Sie müssen nur neugierig werden – und vielleicht ein bisschen mutig.
Eine wachsende Zahl von Teams baut "Stack-Sanity-Checks" in jedes Audit ein, unabhängig davon, ob es im Scope liegt. Es geht nicht darum, Budgets zu kürzen – es geht darum, die Tools richtig auf das Problem zuzuschneiden.
Und oft ist der schwierigste Teil nicht, das Tool zu ersetzen – es ist, sich durch die internen Politik-Fragen zu navigieren, wer es ursprünglich ausgewählt hat.
Halten Sie Ausschau nach den Minen
Hier steckt eine Lektion für jeden Dev, Ops-Ingenieur und Manager mit auch nur ein bisschen Einfluss auf Infrastruktur-Entscheidungen: Behandeln Sie Ihren Stack wie etwas Lebendiges. Überprüfen Sie ihn. Refaktorisieren Sie ihn. Hinterfragen Sie ihn.
Sie könnten Folgendes entdecken:
Dieses teure Gateway? Ersetzt durch etwas, das in ein Dockerfile passt.
Diese Monitoring-Suite mit fünf Dashboards, die niemand checkt? Getauscht gegen ein Grafana-Setup, das Sie wirklich kontrollieren.
Dieser aufgeblähte VM-Cluster? Umgezogen auf Container, die skalieren, weil sie einfach sind.
Sie müssen kein Startup sein, um schlank zu denken. Selbst große Organisationen können von ein bisschen OSS-getriebenem Frühjahrsputz profitieren.
Letzter Gedanke: Einfachheit gewinnt
Am Ende des Tages geht es hier nicht nur um Kubernetes oder API-Gateways. Es geht darum, den Kreislauf des "Naja, es ist schon da"-Denkens zu durchbrechen.
Denn unter der Haube vieler moderner Systeme tickt leise eine 100.000-$-Zeitbombe. Und alles, was es braucht, um sie zu entschärfen, ist jemand, der bereit ist zu fragen: "Hey, brauchen wir das eigentlich noch?"
Manchmal ist der klügste Schachzug nicht, etwas Neues zu bauen – sondern das zu entfernen, was Ihnen nicht mehr dient.