Die Autobauer haben im Mai auf dem deutschen Markt die eigenen Preisnachlässe für Elektroautos zurückgefahren. Der monatliche Neuwagen-Marktbericht des privaten Center Automotive Research (CAR) sieht das als direkte Folge der staatlichen Förderung, die seit Mai rückwirkend für Anmeldungen im laufenden Jahr gezahlt wird.

„Es scheint, die Autobauer testen den Markt“, sagt Studienleiter Ferdinand Dudenhöffer. Der Abstand bei den Transaktionspreisen zwischen E-Autos und Verbrennern werde entgegen dem vorherigen Trend wieder größer. Nach den Markterhebungen bei den 20 meistverkauften Elektrofahrzeugen ist der durchschnittliche Preisnachlass von 19,5 Prozent im Januar auf nun 18,6 Prozent zurückgegangen. Elektroautos waren damit in der Anschaffung im Schnitt 1971 Euro teurer als ein vergleichbarer Verbrenner. Die staatliche Förderung ist dabei nicht eingerechnet.

Weniger Rabatt für kleine Stromer

Sinkende Preisnachlässe beobachtet CAR vor allem bei kleineren E-Autos, die eher in das Anforderungsprofil der förderberechtigten Haushalte passen dürften. Förderfähig sind Kauf und Leasing neuer Elektroautos, bestimmter Plug-in-Hybride, die sowohl mit Strom als auch mit Treibstoff fahren können, sowie Elektroautos mit sogenannten Reichweitenverlängerern. Letztere sind kleine Verbrennungsmotoren, die die Reichweite von Elektroautos erhöhen.

Voraussetzung ist eine Zulassung des Fahrzeugs seit dem 1. Januar dieses Jahres. Die Höhe des staatlichen Zuschusses hängt von Fahrzeug, Haushaltseinkommen (höchstens 80.000 Euro) und Familiengröße ab und kann zwischen 1500 und 6000 Euro betragen. Die Prämie gilt nur für Privatautos, nicht für Dienstwagen. Die Fördermittel sollen für bis zu 800.000 Fahrzeuge ausreichen.

(nie)

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)