🧠Editorial
Wer trägt eigentlich die Konsequenzen unserer Technologieentscheidungen?
Diese Frage zieht sich für mich durch einige der spannendsten Meldungen dieser Woche. Die Schweiz kauft Public Cloud ein und akzeptiert dabei weitgehend Standardverträge der Hyperscaler. Deutschland gibt den Plan auf, dem BSI eine stärkere zentrale Rolle zu geben. Google muss 403 Millionen Euro wegen des Umgangs mit Standortdaten zahlen. Und Donald Trump kündigt einen KI-Zar an, dessen Kompetenzen noch weitgehend unklar sind.
Technologie ist eben selten nur eine technische Entscheidung. Verträge, Zuständigkeiten und Geschäftsmodelle sind mindestens genauso relevant wie die Technologie selbst.
Daneben freue ich mich, diese Woche zwei Themen etwas mehr Raum geben zu können: level66.network, unseren Partner für den Edge-Standort in Frankfurt, und Marc Jeglewski von ConsultIT, der in seinem Gastbeitrag erklärt, warum Cloud-native kein fertiger Zustand, sondern ein fortlaufender Prozess ist.
Dazu gibt es Security Alerts, Short News und natürlich wieder Neues aus dem Kubernetes-Ökosystem.
Viel Spaß beim Lesen!
📰 Tech-News:
Schweizer Bundes-Cloud: Standardverträge statt Verträge für einen Staat
2021 vergab die Schweizer Bundeskanzlei Aufträge für Public-Cloud-Dienste der Bundesverwaltung an Microsoft, Amazon, IBM, Oracle und Alibaba. Die Leistungen werden dabei in den Rechenzentren der Hyperscaler erbracht – und nicht in den Rechenzentren des Bundes.
Die Vergabe sorgte bereits damals für Diskussionen. Im Mittelpunkt stand die Frage, ob sensible Daten Schweizer Bürgerinnen und Bürger über die Cloud bei amerikanischen oder chinesischen Behörden und Geheimdiensten landen könnten.
Inzwischen kann man genauer hinschauen.
Die Republik setzte gemeinsam mit Öffentlichkeitsgesetz.ch und im Fall von Amazon auch vor Gericht die Veröffentlichung der Verträge durch. Seit Herbst 2025 sind sie öffentlich einsehbar.
Adrienne Fichter hat die Verträge nun für „Das Netz ist politisch“ analysiert.
Untersucht hat sie die Rahmenverträge mit Microsoft, Amazon, Oracle und Alibaba. IBM ließ sie aus Ressourcengründen außen vor. Für ihre Analyse sprach Fichter nach eigenen Angaben mit Jurist und zog zusätzlich Perplexity, Gemini und Claude heran.
Sie untersuchte fünf Bereiche: Haftung, Audit- und Kontrollrechte, Datensouveränität, Governance und Exit-Möglichkeiten.
Ihr Fazit fällt deutlich aus: Bei den vier untersuchten Vertragswerken handelt es sich im Kern um gewöhnliche Standardverträge, wie sie auch Unternehmen bekommen – und nicht um maßgeschneiderte Verträge für die besonderen Anforderungen eines Staates.
Dabei gibt es durchaus schweizspezifische Regelungen.
Bei AWS gelten beispielsweise Schweizer Recht und Bern als Gerichtsstand. Der Bund kann Verschlüsselungsmethoden einsetzen, bei denen er den Masterkey selbst kontrolliert. AWS verpflichtet sich zudem, bestimmte ausländische Behördenanfragen anzufechten. Auch die anderen untersuchten Verträge enthalten eigene Regelungen für den Bund.
An der grundsätzlichen Vertragslogik ändert das laut Fichters Analyse jedoch wenig.
AWS schließt unter anderem die Haftung für Datenverlust aus und begrenzt seine Gesamthaftung grundsätzlich auf den Betrag, den der Bund in den zwölf Monaten vor dem Schadensereignis für den betroffenen Dienst gezahlt hat. Bei Microsoft ist der entsprechende Teil zur Haftung im veröffentlichten Rahmenvertrag fast vollständig geschwärzt.
Auch die Kontrollmöglichkeiten unterscheiden sich erheblich. Microsoft sieht laut Analyse kein eigenständiges tiefes Prüfrecht des Bundes in die technische Architektur oder reguläre Vor-Ort-Kontrollen vor. Alibaba ermöglicht bei konkreten Anlässen dagegen ausdrücklich physischen und logischen Zugang im Rahmen eines Audits. Oracle räumt ebenfalls Vor-Ort-Prüfungen ein.
Interessant ist deshalb Fichters Gesamtbewertung: Ausgerechnet Alibaba bietet dem Bund nach ihrer Analyse bei Auditrechten, Data Governance und Exit-Fähigkeit ein leicht vorteilhafteres Vertragswerk als die anderen drei untersuchten Anbieter.
Genutzt werden laut dem im Artikel aufgeführten Stand der Public-Cloud-Bezüge dennoch vor allem Microsoft und AWS.
Besonders deutlich wird der Standardcharakter der Verträge beim Exit. Bei Microsoft kann der Bund seine Daten nach Vertragsende selbst extrahieren. Eine Verpflichtung zu aktiver Unterstützung bei der Migration ist nicht enthalten. Alibaba bietet solche Unterstützung nur nach separater Vereinbarung und gegen zusätzliche Vergütung. Bei Oracle verbleiben 60 Tage für den eigenständigen Export; Transition Services müssen ebenfalls separat vereinbart und bezahlt werden.
Fichters zentraler Kritikpunkt ist deshalb nicht, dass überhaupt Public Cloud eingesetzt wird.
Es ist die Vertragsgrundlage.
Wenn ein Staat kritische IT-Aufgaben auslagert, müssten Verantwortlichkeiten, Ausfälle und der spätere Ausstieg entsprechend geregelt werden. Nach Fichters Analyse akzeptiert die Bundesverwaltung stattdessen bei allen vier untersuchten Anbietern im Kern deren globale Standardverträge.
Die Rahmenverträge wurden im vergangenen Jahr noch einmal um fünf Jahre verlängert und gelten damit bis 2030.
Fichter zieht daraus eine klare Verbindung zur digitalen Souveränität: Dazu gehören ihrer Ansicht nach auch Verträge mit Cloud-Anbietern, die Resilienz, Autonomie, Data Governance und Auditfähigkeit berücksichtigen.
Ein Staat kann Standard-Cloud einkaufen. Er sollte dann aber nicht erwarten, dass Standardverträge automatisch seine Souveränitätsinteressen abbilden.
🔗https://dnip.ch/2026/09/16/die-schlechten-cloud-rahmenvertraege-des-bundes/
Bund gibt Plan für stärkere Rolle des BSI auf
Die Bundesregierung gibt den Plan auf, das Bundesamt für Sicherheit in der Informationstechnik (BSI) per Grundgesetzänderung zu einer Zentralstelle für Informations- und Cybersicherheit auszubauen. Darüber berichtet heise.
Der Kern des Problems: Deutschland organisiert seine Cyberabwehr entlang föderaler Zuständigkeiten. Das BSI ist eine Bundesbehörde und kann bei Angriffen auf Landesbehörden nicht einfach eingreifen. Eine Grundgesetzänderung sollte genau diese Grenzen neu ordnen und dem BSI eine stärkere zentrale Rolle geben.
Daraus wird nun nichts.
Das Bundesinnenministerium will stattdessen den bestehenden verfassungsrechtlichen Rahmen ausschöpfen. Es verweist auf Kooperationsvereinbarungen mit 14 Bundesländern und zusätzliche Möglichkeiten durch die Umsetzung der NIS2-Richtlinie.
Für mich ist diese Kehrtwende angesichts der aktuellen Bedrohungslage kaum nachvollziehbar.
Deutschland leistet sich eine hochgradig fragmentierte Verwaltungs-IT, massive Abhängigkeiten von proprietären Technologien und gleichzeitig eine Cyberabwehr, deren Handlungsmöglichkeiten an föderalen Zuständigkeiten enden können.
Microsoft ist tief in der öffentlichen Verwaltung verankert. Parallel wächst die Bedeutung der Cloud-Infrastrukturen großer US-Konzerne. Wir reden über digitale Souveränität, während zentrale Teile unserer digitalen Infrastruktur von Unternehmen kontrolliert werden, auf deren strategische Entscheidungen Deutschland und Europa nur begrenzten Einfluss haben.
Gerade unter diesen Bedingungen müsste der Staat seine eigenen Fähigkeiten konsequent stärken.
Stattdessen bleibt bei einem Cyberangriff zunächst relevant, welche staatliche Ebene betroffen ist und wer zuständig ist. Der Angreifer muss sich mit solchen Fragen nicht beschäftigen.
Das ist der entscheidende Widerspruch: Cyberangriffe sind längst grenzüberschreitend, automatisiert und hochgradig professionell. Unsere Abwehr bleibt föderal fragmentiert.
Eine stärkere Rolle des BSI hätte dieses Problem nicht allein gelöst. Aber den dafür vorgesehenen strukturellen Schritt jetzt aufzugeben, ist das Gegenteil der Konsequenz, die Deutschland aus der aktuellen Sicherheitslage ziehen müsste.
Digitale Souveränität beginnt nicht bei Sonntagsreden. Sie beginnt bei Strukturen, die im Ernstfall handlungsfähig sind.
403 Millionen Euro Strafe für Google wegen Standortdaten-Tracking
Google muss in Frankreich eine Strafe von 403 Millionen Euro zahlen. Hintergrund ist laut heise der Umgang mit Standortdaten von Android-Nutzer. Die französische Datenschutzbehörde CNIL wirft Google vor, Standortinformationen für personalisierte Werbung verarbeitet zu haben, ohne dafür eine ausreichende Einwilligung eingeholt zu haben.
Der Fall ist vor allem deshalb relevant, weil Standortdaten zu den sensibelsten Informationen gehören, die Smartphones erzeugen. Aus ihnen lassen sich nicht nur Bewegungen ableiten. In Kombination mit anderen Daten können sie detaillierte Rückschlüsse auf Alltag, Gewohnheiten und Interessen ermöglichen.
Technisch ist das längst keine Randfrage mehr. Smartphones, Betriebssysteme und digitale Dienste produzieren kontinuierlich Daten, während für Nutzer oft schwer nachvollziehbar bleibt, welche Informationen für welche Zwecke zusammengeführt werden.
Genau hier liegt die größere Dimension der Entscheidung: Datenschutz entscheidet sich nicht erst in Datenschutzerklärungen und Einwilligungsdialogen. Er entscheidet sich in der Architektur digitaler Produkte – bei der Frage, welche Daten überhaupt erhoben werden, wo sie verarbeitet werden und ob ein Dienst auch mit weniger personenbezogenen Informationen funktionieren kann.
Die Höhe der Strafe ist deshalb die Schlagzeile. Die interessantere Frage für die Tech-Branche liegt darunter: Wie viel Datenerhebung ist für einen Dienst tatsächlich technisch notwendig – und wie viel ist Bestandteil des Geschäftsmodells?
Trump will einen KI-Zaren.
Donald Trump hält wenig von der Idee, die Entwicklung künstlicher Intelligenz durch neue Regeln auszubremsen. Sicherheitsbedenken bezeichnete er als „Hoax“. Die entscheidende Leitplanke für KI sei ein „starker und kluger Präsident“.
Jetzt kündigt genau dieser Präsident eine „AI Force“ an. An ihre Spitze soll ein neuer „KI-Zar“.
Das klingt zunächst nach mehr staatlicher Kontrolle. Heise formuliert entsprechend vorsichtig, die neue Einheit könne als erster Versuch der Trump-Regierung interpretiert werden, doch eine staatliche Aufsicht über KI zu etablieren.
Mich interessiert an dieser Ankündigung allerdings weniger, dass kontrolliert werden soll.
Sondern wer die Kontrolle kontrolliert.
Bislang gibt es weder ein öffentlich bekanntes Mandat noch klare Zuständigkeiten oder ein Budget für die „AI Force“. Trump hat lediglich angekündigt, ihren KI-Zaren demnächst zu benennen.
Damit wäre die Aufsicht zunächst einmal bemerkenswert nah an dem Präsidenten angesiedelt, der gleichzeitig verspricht, das Wachstum der KI-Industrie „in keiner Weise“ zu behindern. Für problematisches Verhalten verweist Trump auf das bereits bestehende Straf- und Zivilrecht.
Das ist eine interessante Vorstellung von Aufsicht.
Denn eine starke staatliche Kontrolle kann Macht begrenzen. Sie kann Macht aber auch bündeln. Der Unterschied liegt in ihrer institutionellen Unabhängigkeit, ihren gesetzlichen Kompetenzen und darin, wem gegenüber sie rechenschaftspflichtig ist.
Genau dazu wissen wir bei Trumps „AI Force“ bislang praktisch nichts.
Wir wissen dagegen ziemlich genau, was Trump von KI-Politik erwartet: Die USA sollen im Wettlauf mit China führen, die Entwicklung soll nicht gebremst werden und zusätzliche Regulierung betrachtet er mit großer Skepsis.
Und nun soll ein von seiner Regierung bestimmter KI-Zar darüber wachen.
Vielleicht bekommt dieser Zar weitreichende unabhängige Kompetenzen, klare gesetzliche Grenzen und institutionelle Distanz zum Weißen Haus.
Das wäre dann tatsächlich interessant.
Bis dahin drängt sich mir eine andere Lesart auf: Trump reagiert auf die Forderung nach mehr Kontrolle nicht unbedingt mit weniger Macht über KI-Politik.
Sondern mit einer neuen Stelle, an deren Spitze jemand steht, den er selbst auswählt.
🔗https://www.heise.de/news/Trump-will-KI-Zar-um-Sorgen-um-Sicherheit-zu-zerstreuen-11459245.html
💚In eigener Sache:
Unsere Edge Cloud wächst
Mit der ayedo Edge Cloud bauen wir eine verteilte europäische Cloud-Infrastruktur auf. Workloads sollen dort laufen können, wo sie gebraucht werden – auf einer souveränen, leistungsfähigen Infrastruktur und ohne unnötige Abhängigkeit von den großen Hyperscalern.
Doch eine Edge Cloud besteht nicht nur aus Compute, Storage und Kubernetes. Entscheidend ist auch, wie die einzelnen Standorte mit dem Internet verbunden sind.
Genau deshalb arbeiten wir in Frankfurt mit level66.network zusammen.
level66 bringt umfangreiches Peering, hohe Netzwerkkapazitäten und DDoS-Mitigation direkt auf Netzwerkebene mit. Das Unternehmen zeigt damit ziemlich gut, warum wir bei Edge-Infrastruktur nicht erst beim Server anfangen zu denken.
Denn bevor ein Request einen Pod erreicht, hat das Netzwerk längst einen erheblichen Teil der Arbeit erledigt.
In unserem neuen Blogpost stellen wir level66 vor und zeigen, welche Rolle der Partner für unsere Edge Cloud spielt – und warum bei level66 ausgerechnet Hosting nur das Nebenprodukt ist.
Jetzt lesen: „level66 – Wenn Hosting nur das Nebenprodukt ist“
🔗https://ayedo.de/posts/level66-wenn-hosting-nur-das-nebenprodukt-ist/
🗣️Gastbeitrag:
Cloud-native: Die Technologie, die mit euch denkt
von Marc Jeglewski
Viele Unternehmen stehen vor der Herausforderung, ihre IT-Infrastruktur so zu gestalten, dass sie flexibel, skalierbar und zukunftssicher ist. Da fällt es leicht, sich für stark integrierte Angebote eines Hyper-Scalers zu entscheiden. Sie werden geliefert, laufen, man muss sie nicht selbst betreiben, herrlich. Oder?
Tatsächlich können solche Lösungen so einige Probleme mit sich bringen. Neben versteckten Kosten und proprietären Lösungen, bei denen Leistungsschwankungen gar nicht so unwahrscheinlich sind, fehlt es oft an Flexibilität und Anpassbarkeit. Aber genau die braucht es, um Innovationen voranzutreiben.
Warum Cloud-native? Weil Stillstand keine Option ist
Besser ist es deshalb, offene Technologien wie Kubernetes einzusetzen. ****Das mag zwar anfangs mehr Arbeit bedeuten, aber nur so bekommt ihr Lösungen, die langfristig funktionieren und mit euren Anforderungen wachsen.
Solche Cloud-native Technologien sind von Grund auf dafür gemacht, sich an eure Software-Bedürfnisse anzupassen und es eurem Team zu ermöglichen, Anwendungen schneller zu entwickeln, sie einfacher zu skalieren und effizienter zu betreiben.
Bereits vergangenes Jahr hat Gartner prognostiziert, dass cloud-Ansätze spätestens bis 2028 der Schlüssel sein werden, um in einer sich schnell verändernden digitalen Landschaft wettbewerbsfähig zu bleiben. Deshalb macht es nur Sinn, seine Anwendungen direkt Cloud-nativ aufzubauen. So kann man schneller auf Marktveränderungen reagieren, Ressourcen effizienter nutzen und Innovationen vorantreiben.
Unsere Herangehensweise: Gemeinsam statt einsam
Bei ConsultIT setzen wir auf Kubernetes, Docker und DevOps, damit euer Wechsel zu cloud-nativen Lösungen so reibungslos wie möglich abläuft. Um sicherzustellen, dass die Lösung perfekt zu euren Bedürfnissen passt, arbeiten wir von Anfang an Hand in Hand mit euch zusammen.
In vier Schritten begleiten wir euch bei der modernen Anwendungsentwicklung
- Gemeinsame Analyse: Wir verstehen eure aktuellen Herausforderungen und identifizieren, wo cloud-native Ansätze in eurer Entwicklung den größten Mehrwert bieten – etwa durch schnellere Iterationen oder bessere Skalierbarkeit.
- Maßgeschneiderte Strategie: Gemeinsam entwickeln wir einen Plan, der eure Entwicklungsziele berücksichtigt, ohne euer Tagesgeschäft zu unterbrechen.
- Praktische Umsetzung: Von der Containerisierung eurer Anwendungen mit Docker bis zur Orchestrierung mit Kubernetes setzen wir die Lösungen direkt in eurem Entwicklungsprozess um.
- Kontinuierliche Optimierung: Auch nach der Einführung bleiben wir an eurer Seite, um sicherzustellen, dass eure Anwendungen stets performant, sicher und zukunftsfähig bleiben.
Cloud-native ist kein Ziel, sondern ein Prozess.
Der Wechsel zu cloud-nativen Technologien ist nichts, was man mit einem Mal umgesetzt bekommt. Es ist eine kontinuierliche Entwicklung. Aber gemeinsam können wir die Herausforderung meistern, damit ihr sie langfristieg nutzen könnt – für mehr Agilität, Flexibilität und Zukunftssicherheit. Denn die beste Technologie ist die, die mit eurem Team wächst.
📰 Short News:
Enterprise-Schwenk: Portainer friert Community Edition ein
Portainer verschiebt Fokus auf Kubernetes; Community Edition bleibt auf 2.x, was Offenheit und gemeinschaftliche Kontrolle in Open-Source-Infrastruktur behindert und potenziell neue Lock-in-Risiken schafft.
🔗 https://www.heise.de/news/Enterprise-Schwenk-Portainer-friert-Community-Edition-ein-11459273.html
Nachfolger von Windows: Staatskanzlei Kiel stellt auf Linux um
Schleswig-Holstein wechselt von Windows zu Linux, demonstriert digitale Souveränität und Aufbau europäischer Open-Source-Infrastruktur im öffentlichen Sektor.
Spotlight on SIG Apps
Kubernetes-Ökosystem wird komplexer; SIG Apps fokussiert auf zuverlässigkeit, Node-Lifecycle und neue Muster wie Agent Sandbox, um Abhängigkeiten, Backward-Compatibility und Souveränität in Deployments zu sichern.
🔗https://kubernetes.io/blog/2026/09/22/sig-apps-spotlight/
Biometrische Gesichtserkennung: BKA will anonym auf Anbieter wie Clearview AI zugreifen
BKA will anonymen Zugriff auf Clearview AI-Daten ermöglichen; wirft Fragen zu europäischer Souveränität, Rechtsraum und Datenschutz auf.
🚨 ALERT:
GitLab, ScreenConnect und JFrog Artifactory werden aktiv angegriffen
Die US-Sicherheitsbehörde CISA warnt vor laufenden Angriffen auf bekannte Schwachstellen in GitLab, ConnectWise ScreenConnect und JFrog Artifactory. Betroffen sind damit Systeme, die in vielen Unternehmen zentrale Funktionen für Softwareentwicklung, Fernwartung und Paketverwaltung übernehmen.
Besonders kritisch ist eine Path-Traversal-Schwachstelle in GitLab Community Edition und Enterprise Edition. CVE-2026-85706 erreicht mit einem CVSS-Score von 10.0 die höchste Risikostufe. Nicht authentifizierte Angreifer können darüber beliebige Dateien von GitLab-Servern auslesen – darunter potenziell Konfigurationsdateien und Secrets. GitLab hat die Lücke mit den Versionen 19.3.2, 19.2.6 und 19.1.8 geschlossen. Cloud-Instanzen wurden bereits aktualisiert, Betreiber eigener Installationen müssen selbst aktiv werden.
Auch JFrog Artifactory steht im Fokus. CISA führt zwei aktiv ausgenutzte Schwachstellen: CVE-2026-42016 kann durch eine unzureichende Token-Prüfung zur Ausweitung von Berechtigungen führen. CVE-2026-42018 kann nicht authentifizierten Nutzern Zugriff auf Ressourcen ermöglichen. Für beide Schwachstellen stehen korrigierte Versionen bereit.
Bei ConnectWise ScreenConnect betrifft CVE-2026-84869 eine besonders schwerwiegende Schwachstelle mit einem CVSS-Score von 9.9. Während einer aktiven Fernwartungssitzung können Dateien ohne Autorisierung oder Bestätigung des Hosts übertragen und ausgeführt werden. Sicherheitsforscher von Huntress beobachten in diesem Zusammenhang wurmartige Aktivitäten. Ab Version 26.6.5 ist die Schwachstelle behoben.
Die Warnungen haben einen entscheidenden Punkt gemeinsam: Es geht nicht um theoretische Angriffsmöglichkeiten. Die Schwachstellen werden laut CISA bereits aktiv ausgenutzt. Für Betreiber selbst gehosteter Instanzen sind die verfügbaren Sicherheitsupdates deshalb unmittelbar relevant.
Bekannte Linux-Lücken werden aktiv angegriffen
Die US-Cybersicherheitsbehörde CISA warnt vor aktiven Angriffen auf drei Schwachstellen im Linux-Kernel. Zwei der Sicherheitslücken stammen bereits aus 2025. Die notwendigen Korrekturen sind verfügbar – trotzdem finden Angreifer offenbar weiterhin verwundbare Systeme.
Besonders kritisch ist CVE-2025-39682 im TLS-Code des Kernels mit einem CVSS-Wert von 9,8. Hinzu kommen CVE-2025-39964 im Kryptografie-Code sowie CVE-2026-53266 im Netfilter-Bridge-Code. Laut den vorliegenden Sicherheitsmeldungen sind unter anderem auch Siemens-Geräte der Reihen SIMATIC und SIPLUS betroffen.
Der Fall zeigt ein bekanntes Problem: Eine geschlossene Sicherheitslücke ist noch lange keine geschlossene Angriffsfläche. Entscheidend ist, ob Updates tatsächlich auf den produktiven Systemen ankommen.
Für IT-Verantwortliche heißt das deshalb: Kernelstände und betroffene Geräte prüfen, verfügbare Updates einspielen und insbesondere exponierte Systeme priorisieren. Bei Linux-basierter Infrastruktur, die außerhalb klassischer Serverlandschaften läuft, lohnt sich ein genauer Blick – gerade dort können Systeme aus den üblichen Patch-Prozessen herausfallen.
Der aktuelle Fall ist weniger eine Warnung vor Linux als eine Erinnerung an konsequentes Vulnerability- und Patch-Management. Open Source macht Sicherheitslücken transparent und ermöglicht schnelle Korrekturen. Wirksam werden diese Korrekturen aber erst, wenn sie auch betrieben werden.
💬 LinkedIn-Beitrag der Woche:
Das Souveränitäts-Paradoxon
Daniel Reinartz, Head of Competence Center Cloud Engineering bei Axians Somnitec AG, beschäftigt sich in seinem Beitrag „Das Souveränitäts-Paradoxon“ mit einem Punkt, der in der aktuellen europäischen Cloud-Debatte häufig zu kurz kommt: Digitale Souveränität lässt sich nicht einfach einkaufen.
Reinartz argumentiert, dass viele Unternehmen derzeit versuchen, ein Architekturproblem über neue Produktkategorien zu lösen. Sovereign Cloud, European Cloud oder Dedicated Cloud können Fragen nach Datenresidenz, Jurisdiktion und Betreiberzugriffen adressieren. Sie beseitigen aber nicht automatisch technologische Abhängigkeiten.
Eine Anwendung bleibt schließlich auch dann abhängig, wenn ihre Daten in Europa liegen, sie aber tief an proprietäre Datenbanken, Identity-Systeme, APIs oder Managementdienste gekoppelt ist. Reinartz bringt es deshalb auf einen entscheidenden Punkt: Technologische Souveränität bedeutet nicht Unabhängigkeit, sondern kontrollierte Abhängigkeit.
Besonders unterstützenswert finden wir seinen Gedanken der „Exit Architecture“. Entscheidend ist nicht allein, welche Technologie heute eingesetzt wird, sondern ob eine Organisation morgen noch in der Lage ist, sie zu ersetzen. Sind Daten portierbar? Lassen sich kritische Komponenten substituieren? Ist das notwendige technische Know-how noch im Unternehmen vorhanden? Und wäre ein Wechsel wirtschaftlich überhaupt realistisch?
Genau diese Perspektive halten wir auch bei ayedo für zentral. Nicht, weil jede proprietäre Technologie grundsätzlich problematisch wäre oder jedes Unternehmen alles selbst betreiben sollte. Sondern weil Wahlfreiheit eine technische Voraussetzung braucht.
Open Source kann dabei ein wichtiger Baustein sein. Sein strategischer Wert liegt nicht allein in offenen Lizenzen, sondern darin, Abhängigkeiten transparenter und Alternativen realistischer zu machen. Aber auch Open Source erzeugt nicht automatisch Souveränität. Entscheidend bleiben Architektur, Betriebsfähigkeit und vorhandenes Know-how.
Reinartz formuliert damit einen wichtigen Gegenentwurf zur aktuellen Sovereign-Cloud-Debatte: Nicht das Etikett eines Angebots entscheidet über Souveränität, sondern die Fähigkeit, eine getroffene Technologieentscheidung später tatsächlich revidieren zu können.
Oder, wie er es am Ende seines Beitrags zusammenfasst: Technologische Souveränität bedeutet, morgen noch eine Wahl zu haben.
🔗 https://www.linkedin.com/pulse/das-souveränitäts-paradoxon-daniel-reinartz-lgree/
☸️Kubernetes-Updates:
Kubernetes 1.37 erkennt ungenutzte PVCs
Mit Kubernetes 1.37 lässt sich einfacher erkennen, welche PersistentVolumeClaims (PVCs) noch gebraucht werden – und welche nicht.
Das ist vor allem bei größeren Clustern hilfreich. Wird ein Pod gelöscht, bleibt sein PVC in Kubernetes normalerweise bestehen. Das ist Absicht, denn Kubernetes möchte gespeicherte Daten nicht automatisch löschen. Mit der Zeit können sich dadurch aber PVCs ansammeln, die niemand mehr verwendet und die trotzdem weiterhin Speicherplatz belegen.
Kubernetes 1.37 macht solche Fälle direkt am PVC sichtbar. Dafür bekommt jeder PVC eine neue Unused-Condition. Verwendet kein aktiver Pod den PVC, steht sie auf Unused=True. Greift mindestens ein aktiver oder wartender Pod darauf zu, lautet der Status Unused=False.
Zusätzlich zeigt lastTransitionTime, seit wann sich der PVC in diesem Zustand befindet. So lässt sich zum Beispiel feststellen, welche PVCs bereits seit mehr als 30 Tagen ungenutzt sind und deshalb überprüft werden sollten.
Wichtig dabei: Kubernetes betrachtet auch einen noch wartenden (Pending) Pod als Nutzer eines PVC. Erst wenn kein nicht beendeter Pod mehr auf den PVC verweist, gilt er als ungenutzt. Bereits erfolgreich abgeschlossene oder fehlgeschlagene Pods zählen dagegen nicht mehr.
Die Funktion gab es bereits mit Kubernetes 1.36 als experimentelles Alpha-Feature. Mit Kubernetes 1.37 erreicht PersistentVolumeClaimUnusedSinceTime den Beta-Status und ist standardmäßig aktiviert.
Damit liefert Kubernetes nun selbst eine wichtige Information, für die Betreiber bisher häufig eigene Skripte oder Monitoring-Lösungen benötigten: Welche PVCs werden noch verwendet – und seit wann liegen andere ungenutzt herum?
🔗 https://kubernetes.io/blog/2026/09/21/kubernetes-v1-37-pvc-last-used-time/