Die von iX und dpunkt.verlag ausgerichtete Online-Konferenz Mastering GitOps geht in die heiße Phase der Anmeldung: Bis einschließlich 3. Juni 2026 sind noch Tickets zum Frühbucherpreis von 249 Euro (zzgl. Mehrwertsteuer) erhältlich. Die eintägige Veranstaltung am 25. Juni 2026 richtet sich an Softwareentwicklerinnen und Softwareentwickler, DevOps Engineers sowie Plattform-Teams, die ihre Deployment-Pipelines belastbarer, sicherer und nachvollziehbarer aufstellen wollen. Der Fokus liegt unter anderem auf der Automatisierung und Skalierung von GitOps.

Vom Deployment-Werkzeug zum Fundament des Platform Engineering

Inhaltlich nimmt das Programm die Entwicklung von GitOps zum tragenden Betriebsmodell für Platform Engineering, Multi-Cluster-Setups und Progressive Delivery in den Blick. Tools wie Argo CD, Flux, Kargo, Pulumi und Crossplane bilden weiterhin das Rückgrat moderner GitOps-Stacks, ergänzt um Ansätze wie Policy-driven GitOps.

Den Auftakt übernimmt Artem Lajko, Head of Platform Engineering bei iits consulting, mit einer Bestandsaufnahme der GitOps-Evolution – von der schlanken deklarativen Deployment-Strategie hin zum zentralen Baustein moderner Developer Platforms. Regina Voloshin von Octopus Deploy, Maintainerin von Argo CD, widmet sich in ihrem Vortrag „Eliminating Hidden Argo CD Pitfalls in Your GitOps Workflow“ den typischen Fallstricken beim produktiven Einsatz: Skalierungsprobleme in großen Multi-Cluster-Umgebungen, sicheres Secrets-Management und der Umgang mit Konfigurationsdrift, also den Abweichungen zwischen tatsächlichem Cluster-Zustand und dem in Git deklarierten Soll-Zustand.

Autopilot, schnellere Previews und Rendered Manifests

Thorsten Wussow (Slix) zeigt, wie sich GitOps mit dem Flux Operator in den Autopilot-Modus überführen lässt. Dag Bjerre Andersen (Egmont) und Sergey Shevchenko (TangoMe) demonstrieren in einem gemeinsamen Talk, wie sich die Vorschau von Pull-Request-Änderungen mit Argo CD spürbar beschleunigen lässt.

Christian Hernandez von Cisco befasst sich mit dem Rendered-Manifests-Pattern in Verbindung mit OCI-Registries. Statt Helm-Charts oder Kustomize-Overlays erst zur Laufzeit aufzulösen, werden fertige Kubernetes-Manifeste vorab gerendert und als unveränderliche Artefakte in OCI-Registries abgelegt. Damit entfallen Laufzeit-Mutationen durch Argo CD, und es entsteht eine eindeutige Single Source of Truth. Seit Argo CD 3.1 werden OCI-Registries nativ unterstützt – ein Plus für Nachvollziehbarkeit, Auditierbarkeit und Team-Kollaboration.

Praxisbericht von Zeiss: DORA-Metriken in Backstage

Wie sich GitOps in einem Industriekonzern skalieren lässt, schildert Alexander Troppmann von Carl Zeiss. Sein Team betreibt Argo CD in einer Multi-Tenant-Architektur als Kern des konzernweiten Platform-Engineering-Projekts. Die DORA-Kennzahlen Deployment Frequency, Lead Time for Changes, Change Failure Rate und Failed Deployment Recovery Time laufen in Backstage als Single Source of Truth zusammen und werden über Custom Tooling in die GitOps-Welt überführt. Auf diese Weise messen die Entwicklungsteams ihre Deployment-Performance kontinuierlich und behalten zugleich die Plattformkosten im Blick.

Bis 3. Juni 2026 noch Frühbuchertickets sichern

Wer noch ein Ticket zum Frühbucherpreis von 249 Euro buchen möchte, hat bis 3. Juni 2026 Zeit, danach kostet es 299 Euro (jeweils zzgl. MwSt.). Teams ab drei Personen profitieren von Gruppenrabatten. Wer über den Fortgang der Konferenz Mastering GitOps auf dem Laufenden bleiben möchte, kann sich auf der Website für den Newsletter registrieren. Der aktuelle Hashtag auf Social Media lautet #masteringgitops.

(map)

Die Debatte über die digitale Souveränität in Europa macht vor den Rechnerwolken längst nicht mehr Halt. Im Zentrum der Kritik steht aktuell das Bundesamt für Sicherheit in der Informationstechnik (BSI) mit seinem jüngst veröffentlichten Kriterienkatalog C3A (Cloud Computing Autonomy). Der europäische Cloudverband CISPE und mehrere Provider vom alten Kontinent erheben dagegen schwerwiegende Vorwürfe: Die Bonner Behörde verspreche zwar Unabhängigkeit, legitimiere letztlich aber den ununterbrochenen Einsatz von US-Hyperscalern als Subunternehmer. Sie öffne damit extraterritorialen Risiken sowie strukturellen Vendor-Lock-ins Tür und Tor.

Die heise online vorliegende CISPE-Analyse macht große Schlupflöcher im C3A-Katalog aus. So sehe das Framework zwar vor, dass der primäre Cloud-Anbieter unter europäischer Kontrolle stehen müsse. Bei den weitaus wichtigeren Subunternehmern weiche das BSI diese Linie aber drastisch auf: Für sie wird lediglich eine registrierte Hauptniederlassung in Deutschland oder der EU verlangt.

Eine tatsächliche Eigentumskontrolle durch europäische Unternehmen ist nicht vorgeschrieben. Europäische Anbieter können im Rahmen von C3A also problemlos auf US-Infrastruktur-Giganten setzen, die vollumfänglich dem Zugriff ausländischer Behörden und Gesetzen wie dem US Cloud Act ausgesetzt sind. Damit müssen sie gegebenenfalls Daten an Behörden in den USA herausrücken.

Bürokratie statt echtem Schutz

Diese extraterritoriale Offenheit wird in dem Regelwerk nicht unterbunden, sondern formalisiert. Der Katalog verlangt von den Anbietern lediglich eine jährliche Risikoanalyse solcher Auslandszugriffe. Die Kritiker bemängeln dies als Papiertiger-Bürokratie: Es gebe keinerlei Verpflichtung, die identifizierten Risiken technisch zu minimieren oder organisatorisch auszuschließen. Da sich die Betrachtung zudem nur auf kundengenerierte Informationen beziehe, blieben andere kritische Datentöpfe wie Metadaten, Telemetrie oder Account-Informationen völlig schutzlos.

Gleichzeitig baut das BSI Hürden auf, die für den breiten europäischen Mittelstand unüberwindbar scheinen. Der Katalog fordert etwa, dass Anbieter innerhalb der EU eine tägliche Kopie des Quelltextes vorhalten und eigene Build-Umgebungen betreiben müssen, um Software im Ernstfall unabhängig patchen zu können. Was nach maximaler Resilienz klingt, geht dem CISPE zufolge aber an der wirtschaftlichen Realität vorbei. Kein europäisches mittelständisches Unternehmen verfüge über die Verhandlungsmacht oder die Ressourcen, um von globalen Softwarekonzernen den Zugriff auf proprietären Source-Code zu erzwingen oder komplexe Drittsoftware in Eigenregie weiterzuentwickeln.

Wettbewerbsnachteil für den Mittelstand

Damit bewirkt das Framework das exakte Gegenteil seines Ziels: Es schließt den innovativen europäischen Mittelstand de facto aus und begünstigt jene Konstrukte, die ohnehin auf die Technologie der US-Hyperscaler aufsetzen. Als prominentes Beispiel nennen die Autoren der Stellungnahme das deutsche Cloud-Modell Delos von SAP und Microsoft. Solche Großprojekte könnten die extremen Anforderungen an die Quellcode-Hinterlegung erfüllen. Sie zementierten so aber genau jene technologische Abhängigkeit, die Europa eigentlich überwinden wolle.

Verschärft wird das Problem durch das Fehlen jeglicher Interoperabilitäts- oder Portabilitätsvorgaben, die einen Schutz vor unfairem Anbieterwechsel oder plötzlichen Kündigungen bieten würden. Das BSI fokussiere sich fast ausschließlich darauf, dass der Provider selbst im Krisenfall betriebsbereit bleibt, moniert der Verband. Die Freiheit des Kunden, seine Daten flexibel zu migrieren oder sich von proprietären Systemen zu lösen, spiele in dem Katalog keine Rolle.

Richtungsentscheidung für Europa

Angesichts des von der EU-Kommission im Kontext des Pakets für technologische Souveränität geplanten Cloud & AI Development Act (CADA) droht das BSI-Rahmenwerk einen gefährlichen Präzedenzfall zu schaffen. Die europäische Tech-Szene steht vor der Richtungsentscheidung, welche Definition von digitaler Souveränität künftig gelten soll: Eine echte operative und technologische Unabhängigkeit oder eine bürokratisch kontrollierte, aber fortwährende Interdependenz von den globalen Tech-Monopolen.

Demgegenüber unterstrich jüngst Luise Kranich, Leiterin der Abteilung Technologiestrategie beim BSI, dass Souveränität nicht mit Isolation gleichzusetzen sei: Völlige Autarkie und maximaler Einfluss auf die Anbieter sei nicht nur nicht möglich, sondern auch nicht gewünscht. Das Amt fokussiere sich mit C3A stattdessen darauf, Abhängigkeiten kontrollierbar zu gestalten. Dass der Entwurf US-Konzernen vorab zur Prüfung vorlag, verteidigte Kranich als strategischen Härtetest: „Wenn sie sagen: ‚Könnt ihr so machen‘, dann sind wir nicht streng genug.“ Die Hyperscaler müssten erkennen, dass mehr gefordert sei „als ein Projektchen in einem deutschem Rechenzentrum“.

(nie)

Amin Vahdat trägt den offiziellen Titel Chief Technologist für KI und Infrastruktur bei Google. Damit ist er nicht nur für den Compute-Bereich zuständig, der die Cloud-KI-Infrastruktur einschließt. Er kümmert sich auch um das Design von Googles internem und externem Netzwerk, die zahlreichen Rechenzentren und die dort verwendeten Plattformarchitekturen – von den eingekauften GPUs und anderen Beschleunigern über die Server bis zu Googles hauseigenen KI-Chips.

Die Tensor Processing Units (TPUs) haben in den vergangenen zehn Jahren acht Generationen durchlaufen. Die neueste Generation besteht aus zwei Varianten und wurde im April vorgestellt. Im Interview mit heise online spricht der promovierte Informatiker Vahdat, der seit 16 Jahren bei Google arbeitet und davor unter anderem Professor an der University of California in San Diego war, über Googles KI-Hardware.

heise online: Herr Vahdat, Sie haben jetzt erstmals spezielle TPU-Varianten für das Training (8t) und die Inferenz (8i). Was genau macht die neuen TPUs aus diesem Jahr besser als die alten?

Amin Vahdat: Mit unserer achten TPU-Generation haben wir uns vom Konzept eines einzelnen, generischen Beschleunigers gelöst, weil wir überzeugt sind, dass sich die physikalischen Gegebenheiten von KI-Workloads grundlegend verändert haben.

„Ein einzelner Prompt kann mittlerweile Tausende autonomer Sub-Agenten anstoßen, die dann wiederum mehrstufige Aufgaben ausführen.“

Für das Training von Frontier-Modellen erreicht die TPU 8t jetzt 121 ExaFlops pro Pod und hält einen Goodput von 97 Prozent aufrecht, sodass die Rechenleistung direkt ins aktive Lernen fließen kann. Auf der Serving-Seite verdreifacht die TPU 8i den On-Chip-SRAM auf 384 MB, um den massiven Working-Memory-Bedarf von Agenten direkt auf dem Silizium vorzuhalten. Mit unserer neuen Collectives Acceleration Engine platzieren wir die richtige Menge an Rechenleistung direkt im Netzwerkpfad. Dabei senken wir die interne Latenz um bis zu Faktor fünf und erzielen sehr geringe Antwortzeiten bei komplexem Reasoning.

Solche Verbesserungen zeigen, wie wir das Hochskalieren von KI für Unternehmen durch integrierte Lösungen wirtschaftlich machen können. Das liefert für alle Workloads von vorne bis hinten Verbesserungen.

Sie haben also die Chip-Typen verändert und auch die Namen. Was steckt strategisch dahinter?

Hardware-Entwicklungszyklen dauern bekanntlich Jahre, also mussten wir die Marktentwicklung vorausplanen, noch bevor der aktuelle Boom einsetzte. Wir haben geschätzt, dass die Branche bis 2026 an eine Weggabelung kommen würde, bei der Inferenz- und Serving-Workloads einen erheblichen Anteil der Nachfrage ausmachen.

Wir haben die Architektur daher in zwei spezialisierte Systeme aufgeteilt, weil wir gesehen haben, dass die Workloads für das Training riesiger Modelle und den Betrieb von Echtzeit-KI-Agenten auseinanderlaufen und jeweils angepasste Technologien benötigen. Das „t“ in TPU 8t steht, wie Sie bereits erwähnt haben, für Training, das eine massive Skalierung und hohen Durchsatz für die Entwicklung von Frontier-Modellen erfordert. Das „i“ in TPU 8i steht für Inferenz, die schnelle Verarbeitung mit niedriger Latenz für komplexe Reasoning-Aufgaben verlangt. Dieser Ansatz gibt uns und Kunden die Flexibilität, genau die Hardware auszuwählen, die für ihre spezifischen Workloads optimal ist.

Warum sind solche spezialisierten Chips überhaupt notwendig?

Der Übergang von einfachen Chatbots zu agentischer KI bedeutet, dass ein einzelner Prompt mittlerweile Tausende autonomer Sub-Agenten anstoßen kann, die dann wiederum mehrstufige Aufgaben ausführen. KI-Agenten, die planen, Aufgaben ausführen und lernen, müssen sich auf die Latenz einzelner Operationen konzentrieren können – nicht auf den Durchsatz, der sich erzielen lässt, wenn viele Einzeloperationen gebündelt verarbeitet werden. Historisch hatten wir Hardware für diesen letzteren, durchsatzorientierten Fall optimiert, bei einer grundlegenden Unterstützung für latenzoptimierte Inferenz.

Mit TPU 8i und TPU 8t haben wir die Spezialisierung konsequent weitergetrieben. Auch wenn die TPU 8t als sehr guter Inferenz-Chip dienen könnte, konzentrierten sich alle unsere Optimierungen auf Leistungseffizienz und Skalierung für das Training. Ebenso kann die TPU 8i eigentlich auch als sehr guter Trainings-Chip fungieren, aber alle unsere architektonischen Innovationen zielten auf Inferenz-Latenzoptimierungen. TPU 8i und 8t zeigen, wie wir das grundlegende Compute-Fabric so umbauen, dass Energie- und Skalierungsherausforderungen gelöst werden, an denen generische Infrastruktur zunehmend scheitert.