Von Enterprise-Bloat zu OSS-Brillanz: Eine Kubernetes-Kostensenkungsgeschichte

Es gibt eine unauffällige Art von Tech-Revolution, die nicht in Keynotes oder auf schicken Landingpages passiert, sondern tief in den Infrastruktur-Setups, die die meisten Teams nie infrage stellen. Sie 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, nämlich fragen: "Moment, warum nutzen wir das überhaupt?"

Das Setup: Standard-Kubernetes, Standard-Überausgaben

Dieses Projekt begann mit einer ziemlich routinemäßigen Aufgabe, nämlich 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 steckte ein Enterprise-API-Gateway, ohne großen Traffic und ohne aufwendiges Routing, 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. 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: Es tauschte das Gateway aus.

Kong OSS, ein Open-Source-API-Gateway, trat an dessen Stelle. Es bildete die Funktionalität nicht nur nach, es räumte das Setup gleich mit auf. Kein überengineertes Spaghetti-Gewirr mehr, dafür sauberes, zielgerichtetes Routing. Die Performance blieb gleich, der Footprint wurde kleiner, die Wartbarkeit deutlich besser, und ein 100.000-$-Posten fiel weg.

Aus diesem Moment der Klarheit wurde eine Gewohnheit. Immer 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 berichtete, sein Team habe die 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 gar nichts mehr routen, Enterprise-Monitoring-Plattformen, bei denen sich 80 % des Stacks mit bereits genutzten Open-Source-Tools überschneiden, und 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."

Wenn Trägheit zur Richtlinie wird

Geld ist natürlich ein Teil der Geschichte, aber es geht auch darum, wie Trägheit unbemerkt 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, dass es eine Alternative gibt, weil das Tool "schon immer da war". So entsteht Enterprise-Bloat, aus Unaufmerksamkeit und nicht aus böser Absicht.

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.

Zu oft zahlen Unternehmen aber 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, Geld sparten und zugleich 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 fing es danach 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

Die meisten dieser Einsparungen kamen aus einfachen Fragen: Brauchen wir das wirklich? Was bringt es uns? Kann etwas Einfacheres denselben Job erledigen?

Sie müssen kein Kubernetes-Ninja sein, um so zu fragen. 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 sie im Scope liegen. Dabei geht es darum, die Tools richtig auf das Problem zuzuschneiden, und nicht darum, Budgets zu kürzen. Der schwierigste Teil ist dann oft nicht die Technik, sondern die interne Politik der Frage, wer das Tool ursprünglich ausgewählt hat.

Halten Sie Ausschau nach den Minen

Für jeden Dev, jeden Ops-Ingenieur und jeden Manager mit etwas Einfluss auf Infrastruktur-Entscheidungen steckt hier eine Lektion: Behandeln Sie Ihren Stack wie etwas Lebendiges, überprüfen Sie ihn, refaktorisieren Sie ihn und hinterfragen Sie ihn.

Dabei kann vieles auffallen. Das teure Gateway lässt sich vielleicht durch etwas ersetzen, das in ein Dockerfile passt. Die Monitoring-Suite mit fünf Dashboards, die niemand checkt, wird zu einem Grafana-Setup, das Sie wirklich kontrollieren. Und der aufgeblähte VM-Cluster zieht auf Container um, die skalieren, weil sie einfach sind.

Sie müssen kein Startup sein, um schlank zu denken. Selbst große Organisationen profitieren von ein bisschen OSS-getriebenem Frühjahrsputz.

Letzter Gedanke: Einfachheit gewinnt

Letztlich geht es hier um mehr als 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 eine 100.000-$-Zeitbombe, und um sie zu entschärfen, braucht es nur jemanden, der bereit ist zu fragen: "Hey, brauchen wir das eigentlich noch?"

Manchmal besteht der klügste Schachzug darin, etwas zu entfernen, das Ihnen nicht mehr dient, statt etwas Neues zu bauen.