Kubernetes und Cloud-Souveränität

AWS, Azure, Google Cloud – irgendwo dort laufen eure Workloads. Und solange die Rechnung stimmt und niemand fragt, ist das auch kein Problem.

Nur: die Rechnung stimmt gerade für viele Unternehmen nicht mehr.

Lizenzkosten explodieren, US-Anbieter werden im europäischen Markt zunehmend als geopolitisches Risiko wahrgenommen und die Abhängigkeiten, die sich über Jahre aufgebaut haben, werden plötzlich sehr sichtbar. Der neue Weg heißt: Cloud-Souveränität.

Raus aus der Cloud und zurück ins klassische Datacenter?

Viele Unternehmen denken bei Cloud-Souveränität sofort an einen radikalen Schnitt: alles raus aus Cloud A, alles rein in Datacenter B. Oder von Anbieter A zu Anbieter B. Beides greift zu kurz. Denn wer nur den Ort wechselt, aber die Architektur nicht verändert, verschiebt die Abhängigkeit oft nur an eine andere Stelle.

Für die meisten ist das auch gar keine realistische Option. Zu viele Prozesse basieren inzwischen auf skalierbarer, automatisierter On-Demand-Infrastruktur. Ein reiner Anbieterwechsel löst das Problem aber auch nicht. Er schafft oft nur die nächste Abhängigkeit.

Die Cloutomate-Antwort liegt in hybriden Architekturen: bestehende Datacenter-Ressourcen weiter nutzen, dynamische Workloads bei Bedarf über externe Private-Cloud- oder Public-Cloud-Ressourcen abfedern und trotzdem eine einheitliche Plattform behalten.

Kubernetes ist hierfür genau das Bindeglied, das viele nicht auf dem Schirm haben.Die gute Nachricht: Genau darum geht es eben gar nicht.

Cloud-Souveränität bedeutet nicht, jede Cloud zu verlassen. Es bedeutet, Workloads, Daten, Netzwerke und Abhängigkeiten so zu steuern, dass Unternehmen nicht dauerhaft an einen einzelnen Anbieter gebunden sind. Kubernetes kann dafür eine technische Grundlage schaffen, weil es Workloads in Public Cloud, eigenem Rechenzentrum und hybriden Architekturen orchestrierbar macht.

Wie Kubernetes Cloud-Souveränität ermöglicht

Kubernetes wird oft missverstanden. Die meisten verbinden damit das Ding, das Container startet. Das stimmt und es stimmt auch wieder nicht. Denn das zu sagen ist ungefähr so, als würde man sagen, ein Smartphone ist das Ding, mit dem man telefoniert. Auch das stimmt, ist aber viel zu kurz gegriffen.

Kubernetes kann, wenn es richtig aufgebaut wird, zur gemeinsamen Steuerungsebene für zentrale Teile der Infrastruktur werden. Nicht nur für Container, sondern für Workloads, Netzwerke, Policies, Routing, Firewall-Regeln und Automatisierung.

Der entscheidende Punkt ist, dass sich Kubernetes in sehr unterschiedlichen Umgebungen betreiben lässt:

• In der Public Cloud, etwa bei AWS, Azure oder anderen Hyperscalern
• Im eigenen Rechenzentrum
• In hybriden Architekturen
• An verteilten Standorten

Überall dort, wo Kubernetes-Nodes laufen, lassen sich Workloads abbilden und Traffic durchleiten. Das kann sukzessive und iterativ passieren, während bestehende Systeme weiterlaufen. Damit entsteht eine Ebene, die nicht an einen einzelnen Cloud-Anbieter gebunden ist.

Genau das macht Kubernetes für Unternehmen interessant, die ihre Cloud-Abhängigkeit reduzieren wollen, ohne ihre Infrastruktur mit einem Schlag neu bauen zu müssen.

Kubernetes als Source of Truth für hybride IT-Infrastrukturen

Der eigentliche Hebel entsteht, wenn Kubernetes nicht nur als Runtime genutzt wird, sondern als Source of Truth.

Dann wird Kubernetes zur zentralen Stelle, über die Infrastruktur nachvollziehbar beschrieben, gesteuert und verändert werden kann. Wir sprechen hier nicht über eine Sammlung manuell geklickter Einzelentscheidungen, sondern über Kubernetes als auditierbare, reproduzierbare und automatisierbare Steuerungsebene, über die sich heterogene Prozesse steuern lassen:

• Anlegen und Verwalten von Netzen
• Steuerung von Firewall-Regeln
• Routing
• Troubleshooting auf Applikations-, Netzwerk- und Infrastrukturebene
• BGP-Propagierung für Mikrosegmentierung
• Automatisierung über IaCC und GitOps
• Selbstdokumentierende Infrastruktur

Auch Monitoring, Storage, Netzwerksteuerung und Identitäts- und Zugriffsmanagement lassen sich in einer solchen Architektur zentraler denken. Nicht zwingend als ein einziges Tool für alles, sondern als einheitlicheres Betriebsmodell über verschiedene Umgebungen hinweg.

Egal ob eine Palo-Alto-Firewall (oder sonst eine Firewall) On-Premises steht oder eine Cloud-Firewall genutzt wird: Entscheidend ist, dass die Konfiguration nicht mehr an vielen Stellen verteilt und manuell gepflegt wird, sondern über eine einheitliche Logik steuerbar wird.

Workloads schrittweise migrieren: Kubernetes als Beweglichkeitsschicht

Erst durch diese gemeinsame Steuerungsebene entsteht die Beweglichkeit, die Unternehmen heute brauchen.

Stellt euch Kubernetes wie eine Platte vor, auf der ihr mit Bauklötzchen unterschiedliche Dinge zusammenbauen könnt. Ihr könnt einen Turm abnehmen und an anderer Stelle wieder aufsetzen, ohne dass die gesamte Konstruktion zusammenbricht.

Technisch heißt das: Workloads, Netze und Zugriffsregeln lassen sich schrittweise bewegen. Ein Netz, das heute noch in Azure geroutet wird, kann morgen ins eigene Datacenter verlegt werden. Workloads folgen. Firewall-Regeln und Routing lassen sich anpassen, ohne dass jede Änderung manuell in mehreren Systemen nachgezogen werden muss. Ausfälle werden minimiert.

Das passiert nicht über Nacht. Und es muss auch nicht über Nacht passieren. Darin liegt ja der Vorteil.

Unternehmen können dort anfangen, wo es technisch einfach, wirtschaftlich sinnvoll und organisatorisch realistisch ist. Bei den Low Hanging Fruits. Also bei den Workloads, die heute hohe Kosten verursachen, aber keine zwingenden Cloud-spezifischen Funktionen benötigen. Das freut dann auch die Manager:

Wir sehen in der Praxis regelmäßig 90–95 % Kostenersparnis im Vergleich zu virtuellen Maschinen in der Cloud – inklusive aller Folgekosten – wenn Workloads ins lokale Datacenter wandern.

Viele Cloud-Probleme entstehen nicht, weil Workloads in der Cloud laufen. Sie entstehen, weil Anwendungen, Datenbanken, Fileserver, Identitäten und Netzwerke über Jahre so miteinander verwoben wurden, dass niemand mehr sauber trennen, verschieben oder absichern kann.

Diese Komplexität ist nicht nur ein Kostenproblem. Sie ist auch ein Sicherheitsproblem. Wenn eine Anwendung auf zentrale Fileserver, zentrale Datenbanken, zentrale Identitätsdienste und cloud-spezifische Services zugreift, wird jede Veränderung riskant. Migrationen werden schwer planbar, Testumgebungen lassen sich nur mit Aufwand aufbauen und niemand kann mehr sicher sagen, welche Änderung welche Nebenwirkung hat.

Darum geht es bei moderner Infrastruktur nicht einfach darum, Workloads von A nach B zu schieben. Es geht darum, Anwendungen wieder als möglichst eigenständige Einheiten zu denken und proprietäre Dienste und harte Kopplung dort zu reduzieren, wo sie keinen echten fachlichen Mehrwert liefern. Es geht darum, wieder klare Abhängigkeiten, klare Zugriffsregeln und eine Infrastruktur zu schaffen, die diese Einheiten bewegen kann.An dieser Stelle spielt Kubernetes seine Stärke aus. Es löst nicht magisch jede Altlast auf, bietet aber eine Plattform, um Netze, Workloads und Abhängigkeiten kontrollierter zu beschreiben, zu steuern und schrittweise zu verändern.

Besonders relevant wird das bei Diensten, die erst einmal bleiben müssen. Nehmen wir S3-Buckets auf AWS. Die kann man nicht einfach von heute auf morgen ablösen. Alle Anwendungen, die diese Anbindung nutzen, müssten angepasst werden. Das kostet Zeit, Ressourcen und Fachkräfte, die oft gerade nicht verfügbar sind.

Hier wird Kubernetes als Overlay-Netzwerk interessant, weil es eine Verbindungsebene zwischen den beteiligten Nodes schaffen kann. Wenn virtuelle Maschinen, die früher direkt in AWS lagen, in ein Datacenter verlegt werden, können sie über Kubernetes weiterhin auf S3-Buckets zugreifen, inklusive Authentifizierung und granularer Rechtevergabe pro Workload.

Unternehmen müssen also nicht jede Verbindung sofort kappen. Sie können eine nahtlose, schrittweise Transition vornehmen und dort reduzieren, wo es technisch und wirtschaftlich sinnvoll ist. Was bleibt, bleibt. Aber es bleibt, weil es sinnvoll ist und nicht weil ihr keine Wahl habt.

Warum Kubernetes für Cloud-Souveränität noch nicht Standard ist

Wenn es doch so gut funktioniert, warum ist das dann noch nicht Standard?

Weil die Strategie vieler Unternehmen heute oft immer noch eine andere ist. Cloud-first klingt immer noch modern. Und für bestimmte Unternehmen ist das auch sinnvoll. Es gibt beeindruckende Use Cases. Netflix nutzt zum Beispiel die Cloud, um flexibel zu sein und kosteneffizient zu skalieren. Und wer möchte nicht gerne so skalieren wie Netflix? ;)

Nur ist Netflix eben nicht die Realität der meisten Unternehmen in Deutschland und Europa.

Die Realität sieht anders aus:

Es gibt keine vollständige Microservices-Architektur, stattdessen gewachsene Systeme, Windows-Workloads, die per Lift & Shift in die Cloud geschoben wurden – mit all den Lizenzkosten, dem Virtualisierungs-Overhead und der AD-Verwaltung in der Cloud, die das Ganze teuer und komplex macht. Hinzu kommen Teams, die ohnehin schon mit knappen Ressourcen arbeiten.

Cloud ist kein Allheilmittel. Das wissen inzwischen die meisten. Die Frage ist: Was tun?

Einfach zurück ins eigene Rechenzentrum ist keine Strategie. Eine neue Abhängigkeit durch eine alte zu ersetzen, löst das Problem nicht.

Der bessere Ansatz ist eine Architektur, die Wahlfreiheit schafft. Eine Infrastruktur, in der Workloads, Netze, Policies und Abhängigkeiten so beschrieben und gesteuert werden, dass sie beweglich bleiben.

Welche Vorteile eine teilweise Cloud-Migration bring

Die Hundertprozentlösung ist in den wenigsten Fällen realisierbar. Und das ist okay. Denn selbst eine teilweise Migration bringt echte Vorteile:

• Spürbare und messbare Kostenreduktion
• Reduziertes Risiko durch weniger Abhängigkeit von einzelnen Anbietern
• Mehr Kontrolle über eure Daten, eure Infrastruktur, eure Entscheidungen
• Bessere Vorbereitung auf regulatorische oder politische Veränderungen
• Mehr Transparenz über Netze, Zugriffe und Abhängigkeiten
• Eine Infrastruktur, die sich besser dokumentieren, automatisieren und auditieren lässt

Und falls es irgendwann doch zu einem externen Big Bang kommt – sei es durch neue Steuern auf Tech-Konzerne, politische Veränderungen oder andere externe Schocks – ist der Schaden kleiner, weil ihr bereits angefangen habt, Abhängigkeiten zu reduzieren.

Souveränität entsteht durch Architektur

Souveränität entsteht nicht durch einen einzelnen Cloud-Wechsel. Sie entsteht durch Architekturentscheidungen, die Wechsel wieder möglich machen.

Kubernetes ist dabei nicht die Antwort auf alles. Es ersetzt keine Cloud-Strategie und keine saubere Architekturplanung. Aber es ist eine der besten technischen Grundlagen, um IT-Infrastruktur so aufzubauen, dass Unternehmen Cloud-Dienste bewusster nutzen, Abhängigkeiten kontrollierter reduzieren und wieder mehr Kontrolle, Beweglichkeit und Wahlfreiheit gewinnen.

Das Ziel ist keine nostalgische Rückkehr ins eigene Rechenzentrum. Das Ziel ist Self-Owned Infrastructure: eine Infrastruktur, die Unternehmen verstehen, steuern und weiterentwickeln können, auch wenn einzelne Workloads weiterhin in der Cloud laufen.

Nicht alles muss raus aus der Cloud. Aber Unternehmen sollten wissen, was bleiben muss, was bleiben darf und was längst woanders besser aufgehoben wäre.

Das ist das, was wir bei Cloutomate machen. Nicht, weil digitale Souveränität gerade en Vogue ist, sondern weil wir seit Jahren sehen, dass es funktioniert.

Ihr wollt wissen, wie das für eure Infrastruktur konkret aussehen könnte?

Dann lasst uns anschauen, welche Abhängigkeiten heute kritisch sind und welche Workloads sich sinnvoll zuerst bewegen lassen.