Das Kubernetes-Projektteam hat Version 1.35 veröffentlicht, die insgesamt 60 Neuerungen umfasst – davon 17 stabile Features sowie 19 Beta- und 22 Alpha-Funktionen. Aufbauend auf der seit Version 1.34 als stabiles Feature verfügbaren Dynamic Resource Allocation (DRA) erweitert das neue Release die Möglichkeiten für Ressourcenmanagement und Workload-Sicherheit.

In-place Updates für Pod-Ressourcen und Beta-Features für Sicherheit

Das wohl wichtigste neue stabile Feature erlaubt laut der Ankündigung zu „Timbernetes“ (The World Tree Release) das Anpassen von CPU- und Speicherressourcen laufender Pods, ohne diese neu starten zu müssen. Bisher erforderten solche Änderungen das Neuerstellen von Pods, was insbesondere bei zustandsbehafteten oder Batch-Anwendungen zu Unterbrechungen führen konnte. Die Funktion soll insbesondere vertikales Skalieren vereinfachen.

Native Pod-Zertifikate für Workload-Identität mit automatisierter Zertifikatsrotation stehen nun im Rahmen der Beta-Phase zur Verfügung: Der kubelet generiert Schlüssel, fordert Zertifikate über PodCertificateRequest an und schreibt Credentials gebündelt in das Dateisystem des Pods. Die Knotenbeschränkung erzwingt der kube-apiserver ab dem Zeitpunkt der Zulassung. So sollen sich auch die beim Einsatz von Signierern durch Drittanbieter häufig auftretenden, versehentlichen Verletzungen der Knotenisolationsgrenzen vermeiden lassen. Laut Ankündigung des Kubernetes-Teams eröffnet sich damit auch der Weg zu reinen mTLS-Flows ohne Bearer-Tokens im Ausstellungspfad.

Die native Storage Version Migration ist in Kubernetes 1.35 ebenfalls Beta und standardmäßig aktiviert. Damit rückt die Migrationslogik direkt in die Control Plane. Für StatefulSets steht das maxUnavailable-Feld jetzt ebenfalls standardmäßig zur Verfügung. Es definiert, wie viele Pods während eines Updates gleichzeitig nicht verfügbar sein dürfen, was Updates beschleunigen kann. Die als sicherere YAML-Variante für Kubernetes in Release 1.34 eingeführte KYAML hat auch die Betaphase erreicht und ist standardmäßig aktiviert.

Veraltete und entfernte Funktionen

Das Kubernetes-Projekt hat den Support für cgroup v1 ab Release 1.35 entfernt. Cluster-Administratoren müssen ihre Nodes auf Systeme mit cgroup-v2-Unterstützung migrieren, andernfalls startet der kubelet nicht mehr. Ebenso endet jetzt der Support für die Runtime containerd 1.x – vor dem nächsten Upgrade ist der Wechsel auf containerd 2.0 oder höher erforderlich.

Der IPVS-Modus in kube-proxy gilt nun als veraltet (deprecated). Das Projektteam empfiehlt den Wechsel zu nftables. Zudem hat das Kubernetes-Team angekündigt, Ingress NGINX nur noch bis März 2026 zu pflegen. Danach wird das Projekt archiviert – die Migration zur Gateway API wird empfohlen.

Einen vollständigen Überblick aller Änderungen und Neuerungen liefern der Blogbeitrag zu Kubernetes 1.35 sowie die Release Notes auf GitHub.

(map)

Softwareentwicklung ist kein Selbstzweck, sondern folgt immer einer zugrunde liegenden Fachlichkeit.

Dieser Satz steht gefühlt in jedem meiner Blogposts hier bei Heise Developer. Er ist mein Leitsatz, meine Überzeugung, mein Kompass. Aber 2025 war das Jahr, in dem er für mich mehr Bedeutung bekommen hat als je zuvor.

Warum scheitern so viele Softwareprojekte? Warum werden sie teurer als geplant, dauern länger als versprochen, liefern weniger als erhofft? Die Antwort, die ich immer wieder sehe, lautet nicht: „Weil die Technik versagt hat.“ Die Frameworks waren gut genug. Die Datenbanken schnell genug. Die Cloud skalierbar genug. Nein, die Projekte scheitern, weil die Fachlichkeit vergessen wird. Weil Technik zum Selbstzweck wird. Weil man Datenbanktabellen entwirft, statt zu fragen, was eigentlich passiert.

Dieses Jahr habe ich versucht, dagegen anzuschreiben. Und nicht nur das.

EventSourcingDB: Die Konsequenz der These

Im Mai dieses Jahres haben wir EventSourcingDB veröffentlicht, eine Datenbank, die speziell für Event Sourcing entwickelt wurde. Keine weitere NoSQL-Datenbank, kein weiteres Tool „um des Tools willen“, sondern die technische Konsequenz einer Überzeugung.

Event Sourcing zwingt zum Nachdenken über Fachlichkeit. Man speichert nicht Zustände, sondern fachliche Ereignisse. Nicht „Kunde hat Adresse Y“, sondern „Kundin ist am 15. März an folgende Adresse umgezogen“. Das klingt nach lediglich einem kleinen Unterschied, ist aber ein fundamentaler Perspektivwechsel. Die Technik dient der Domäne, nicht umgekehrt.

Dass EventSourcingDB inzwischen über 10.000 Docker-Downloads verzeichnet, freut mich. Aber mich freut noch mehr, dass offenbar immer mehr Entwicklerinnen und Entwickler nach genau so einem Werkzeug gesucht haben – einem Werkzeug, das Fachlichkeit ernst nimmt.

Der rote Faden: Die wichtigsten Artikel des Jahres

Über 40 Blogposts habe ich 2025 hier bei Heise Developer veröffentlicht. Über Event Sourcing, über Architektur, über KI, über Agilität und ihre Abgründe. Aber wenn ich zurückblicke, bilden sieben davon für mich den Kern dessen, worum es mir eigentlich geht. Sie erzählen zusammen eine Geschichte: Die Geschichte, warum Softwareentwicklung anders gedacht werden muss.

Das Problem sichtbar machen

Beginnen möchte ich mit einem Märchen. In meinem Blogpost „Warum CRUD für Märchen und Unternehmen gleichermaßen ungeeignet ist“ habe ich versucht, ein komplexes Thema über eine einfache Metapher zugänglich zu machen: Der Wolf hat die Großmutter nicht gelöscht – er hat sie gefressen.

CRUD (Create, Read, Update, Delete) ist das Standardvokabular der meisten Anwendungen. Aber es ist ein technisches Vokabular, kein fachliches. Es versteckt, was wirklich passiert. Es reduziert Geschäftsprozesse auf Datenbankoperationen. Und es macht Systeme zu schwarzen Löchern, in denen die Vergangenheit verschwindet.

Das Märchen hat offenbar einen Nerv getroffen. Vielleicht, weil jede Entwicklerin und jeder Entwickler schon einmal vor einem System stand und sich gefragt hat: „Wie ist dieser Datensatz eigentlich in diesen Zustand gekommen?“

Die konzeptionellen Grundlagen

Wenn CRUD das Problem ist, was ist dann die Lösung? Darauf habe ich in zwei Artikeln geantwortet: „Event Sourcing: Die bessere Art zu entwickeln?“ und „CQRS als Grundlage für moderne, flexible und skalierbare Anwendungsarchitektur“.

Event Sourcing bedeutet, nicht den Zustand zu speichern, sondern die Ereignisse, die zu diesem Zustand geführt haben. CQRS bedeutet, Lesen und Schreiben zu trennen, weil beide unterschiedliche Anforderungen haben. Zusammen bilden sie die Bausteine für Systeme, die Fachlichkeit ernst nehmen. Systeme, in denen man nachvollziehen kann, was passiert ist, und in denen man neue Fragen an alte Daten stellen kann.

Die Vertiefung

Konzepte sind das eine, Umsetzung das andere. Deshalb habe ich im Sommer eine siebenteilige Serie geschrieben: „Event-Driven“. Von den Grenzen klassischer Architekturen über die Bausteine Event-getriebener Systeme bis hin zur praktischen Umsetzung am Beispiel einer Stadtbibliothek.

Es war mein umfassendstes Werk zum Thema in diesem Jahr. Und es war mir wichtig zu zeigen, dass Event-getriebene Architektur kein akademisches Konzept ist, sondern ein praktikabler Weg, Software zu bauen, die die Sprache der Domäne spricht.

Technische Tiefe im Dienst der Fachlichkeit

Wer über Event Sourcing spricht, muss auch über Vertrauen sprechen. Wie kann ich beweisen, dass ein bestimmtes Ereignis zu einem bestimmten Zeitpunkt stattgefunden hat? Wie kann ich Nachvollziehbarkeit garantieren, ohne alle meine Daten offenlegen zu müssen?

In „Merkle-Trees: Datenintegrität kryptografisch beweisen“ habe ich gezeigt, wie sich diese Fragen elegant lösen lassen. Merkle-Trees sind keine neue Erfindung. Sie stecken in Git, in Blockchains, in Certificate-Transparency. Aber im Zusammenspiel mit Event Sourcing entfalten sie ihre volle Stärke: Sie machen Nachvollziehbarkeit nicht nur möglich, sondern beweisbar.

Das ist keine technische Spielerei. Das ist relevant für Compliance, für Audits, für die DSGVO. Technik im Dienst realer Anforderungen.

Heilige Kühe hinterfragen

Der letzte Artikel in dieser Reihe ist der jüngste und vielleicht der kontroverseste: „Wendet man DDD auf DDD an, bleibt kein Domain-Driven Design übrig“.

Domain-Driven Design ist in meiner Community so etwas wie eine heilige Kuh. Und ich schätze die Grundideen von DDD sehr. Aber ich beobachte auch, wie DDD selbst zur Selbstbeschäftigung wird. Wie Teams Bounded-Contexts definieren, ohne je mit einer Fachexpertin gesprochen zu haben. Wie Aggregate und Value-Objects zum Selbstzweck werden, statt der Domäne zu dienen.

Das ist keine Kritik an Eric Evans oder an DDD als Idee. Es ist eine Kritik daran, wie wir als Community manchmal Methoden über Ergebnisse stellen. Und es ist ein Plädoyer dafür, auch unsere liebsten Werkzeuge kritisch zu hinterfragen.

So viel ich auch schreibe, am Ende ist es die Community, die diese Themen lebendig macht. Und 2025 hat mir gezeigt, dass ich mit meinen Überzeugungen nicht allein bin.

Im Oktober waren mein Kollege Rendani und ich auf der KanDDDinsky in Berlin – erstmals als Sponsoren und Aussteller für EventSourcingDB. 250 bis 300 Menschen, die unsere Leidenschaft für Domain-Driven Design, Event-Sourcing und durchdachte Softwarearchitektur teilen. Die Gespräche dort haben mir gezeigt: Das Thema hat Momentum. Event-Sourcing und CQRS sind keine Nischeninteressen mehr, die von einer kleinen Gruppe Enthusiasten in isolierten Ecken praktiziert werden.

Besonders gefreut hat mich die Veröffentlichung von OpenCQRS 1.0 durch Digital Frontiers, ein CQRS- und Event-Sourcing-Framework für die JVM mit nativer EventSourcingDB-Integration. Es entsteht ein Ökosystem. Andere bauen auf dem Fundament auf. Das ist die schönste Bestätigung für die Arbeit, die man in ein Projekt steckt.

Und natürlich danke ich Ihnen, den Leserinnen und Lesern, die kommentiert, diskutiert, widersprochen haben. Gerade die kontroversen Artikel haben mir gezeigt, dass das Thema bewegt. Widerspruch ist kein Problem, Gleichgültigkeit wäre eines.

Ausblick: Fachlichkeit, Architektur und KI

Wenn ich auf 2026 blicke, sehe ich ein Thema, das alles andere überlagern wird: Künstliche Intelligenz. Aber nicht so, wie es oft diskutiert wird.

In meinem Blogpost „Event-Sourcing als perfekte Grundlage für KI“ habe ich argumentiert, dass die Diskussion um KI zu oft bei den Modellen beginnt. Welches LLM ist das beste? GPT oder Claude? Aber das ist die falsche Frage. Die richtige Frage lautet: „Welche Daten habe ich?“

Ein durchschnittliches Modell mit hochwertigen Daten wird jedes Spitzenmodell schlagen, das auf minderwertigen Daten trainiert wurde. Und die Daten der meisten Unternehmen sind minderwertig, weil sie in CRUD-Systemen liegen, die nur den aktuellen Zustand kennen. Die Vergangenheit? Überschrieben. Der Kontext? Verloren. Die Kausalität? Nicht rekonstruierbar.

Event Sourcing ändert das. Es liefert kontextreiche, nachvollziehbare Daten. Es beantwortet nicht nur die Frage „Was ist?“, sondern auch „Wie ist es dazu gekommen?“ Und genau das braucht KI.

Gleichzeitig verschiebt sich die Wertschöpfung in der Softwareentwicklung. In „KI macht Entwickler ersetzbar, aber gute Architekten nicht“ habe ich beschrieben, was das bedeutet: Codieren wird zur Commodity. Was bleibt, ist Domänenwissen, Architektur, Modellierung. Das ist kein Untergang für unseren Berufsstand, es ist vielmehr eine Chance für alle, die Fachlichkeit ernst nehmen.

Die Kombination aus Architektur, Fachlichkeit und KI wird in Zukunft immer wichtiger. Wer versteht, wie man Systeme baut, die gute Daten produzieren, wer versteht, wie man KI sinnvoll einsetzt, und wer gleichzeitig die Domäne versteht, für die er entwickelt, der wird gefragt sein. Genau an dieser Schnittstelle arbeite ich gerade an einer Webinar-Reihe für 2026: der tech:lounge 360°. Für alle, die nicht von KI überrollt werden wollen, sondern sie verstehen und nutzen möchten.

Zum Schluss

Softwareentwicklung ist kein Selbstzweck. Das war mein Leitsatz zu Beginn dieses Artikels, und es ist mein Leitsatz am Ende dieses Jahres.

2025 war für mich das Jahr, in dem dieser Satz Gestalt angenommen hat: in EventSourcingDB, in über 40 Blogposts, in Gesprächen auf Konferenzen, in der Arbeit mit Kundinnen und Kunden. Es war ein intensives Jahr, ein produktives Jahr, und ich bin dankbar für alle, die diesen Weg mitgegangen sind.

Ich wünsche Ihnen Zeit zwischen den Jahren. Zeit zum Nachdenken, was eigentlich das fachliche Problem ist, das Sie lösen wollen. Zeit, um innezuhalten und sich zu fragen, ob die Technik, mit der Sie arbeiten, der Fachlichkeit dient oder zum Selbstzweck geworden ist.

Und dann ein Jahr 2026, in dem die Technik wieder das wird, was sie sein sollte: ein Werkzeug im Dienst dieser Fachlichkeit.

Frohe Weihnachten, ruhige und erholsame Feiertage, und einen guten Start ins neue Jahr.

(rme)

Docker Inc. hat angekündigt, ein bisher kostenpflichtiges Produkt fortan kostenlos anzubieten: Docker Hardened Images (DHI). Der Erfinder der Software Docker und Betreiber des Docker Hubs erklärt, damit auf Lieferkettenangriffe zu reagieren, die auch im Containerumfeld vorkommen. Die gehärteten Abbilder enthalten ein aufs absolut Nötige reduziertes Userland einer Distribution und unterscheiden sich dadurch von den sogenannten „Official Images“, die man ohne Login im Docker Hub (hub.docker.com) für viele Anwendungen findet.

Weniger Spuren der Distribution

Als Beispiel reicht ein Blick auf den Webserver Nginx und dessen Abbild: Im öffentlichen Hub gibt es Abbilder mit dem Namen nginx, die auf den Distributionen Alpine oder Debian aufbauen. Neben dem Webserver selbst stecken Teile der Distribution darin. Die meisten Komponenten sind für den Betrieb des Webservers gar nicht nötig und allenfalls hilfreich, wenn man mit Werkzeugen wie docker exec in einen Container springt und darin Fehler sucht. Über den eingebauten Paketmanager (apt oder apk) kann man beispielsweise einen Texteditor nachinstallieren und auf Fehlersuche im Container gehen. Solche Werkzeuge können aber auch zum Einfallstor für Angreifer werden.

Die gehärteten Abbilder enthalten weniger Spuren der Distribution und damit weniger Einfallstore – im Gegenzug aber auch keine Werkzeuge für die spontane Fehlersuche. Zum Vergleich: Das offizielle Nginx-Abbild auf Alpine-Basis (nginx:alpine) ist 21 MByte groß und kommt mit einer bekannten mittelschweren Sicherheitslücke, für die es einen CVE-Eintrag gibt. Die Debian-Variante (nginx:stable-bookworm) ist sogar 67 MByte groß, hat drei Lücken mit hoher Dringlichkeit, drei mittelschwere und ganze 61 mit der Einstufung „low“. Die gehärtete Version auf Alpine-Basis (dhi.io/nginx:1-alpine3.21) ist nur 4 MByte groß und Docker listet keine einzige bekannte Sicherheitslücke. Ein Blick in den Container zeigt: Der Paketmanager apk, der zu Alpine gehört, fehlt im Abbild.

Die gehärteten Abbilder gibt es für viele Anwendungen, für die es auch offizielle Abbilder gibt – darunter MySQL, PHP, Node.js, Traefik und MongoDB. Kein gehärtetes Abbild fanden wir für die MySQL-Alternative MariaDB. Um die Abbilder zu finden, müssen Sie sich im Docker Hub mit einem kostenlosen Account anmelden, über den öffentlichen Bereich des Hubs sind sie aktuell nicht zu finden. Sie landen nach dem Login in einer Übersicht namens „My Hub“ und finden links im Menü den Punkt „Hardened Images“. Um die Abbilder auf einem Server, einer Entwicklermaschine oder in einer CI/CD-Umgebung zu nutzen, müssen Sie dort zuerst den Befehl docker login dhi.io ausführen und sich mit Benutzernamen und einem persönlichen Zugangstoken anmelden. Ein solches Token erzeugen Sie, indem Sie oben rechts auf Ihre Initialen klicken, die „Account Settings“ öffnen und links unter „Personal access tokens“ ein Token erzeugen, das Leserechte hat.

Mehr Service gegen Geld

Neben den Abbildern hat Docker Inc. auch Helm-Charts für Kubernetes-Nutzer veröffentlicht, in denen die gehärteten Abbilder zum Einsatz kommen.

Auch in Zukunft möchte Docker Inc. mit den gehärteten Abbildern Geld verdienen, wie der Blogpost zur Ankündigung erklärt. Wer regulatorische Anforderungen hat und beispielsweise FIPS-konforme Abbilder braucht oder sich eine Reaktion auf kritische CVEs innerhalb von sieben Tagen vertraglich zusichern lassen muss, greift zu den kostenpflichtigen „Docker Hardened Images Enterprise“. Außerdem verspricht Docker erweiterten Support für Anwendungen in Versionen, die von den Entwicklern der Anwendungen nicht mehr unterstützt werden („DHI Extended Lifecycle Support“).

(jam)