Connect with us

Entwicklung & Code

Dynamic Consistency Boundaries: Flexible Konsistenz statt starrer Aggregates


Vielleicht kennen Sie das: Sie arbeiten an einem System mit Event-Sourcing (oder Sie möchten ein neues System damit aufbauen) und haben das Gefühl, dass Sie eigentlich schon recht weit sind. Sie haben eine gute Vorstellung davon, was Ihre Entitäten sind. Sie haben bereits erste Event-Typen formuliert, vielleicht sogar schon die ersten Commands. Doch dann kommt der Punkt, an dem Sie eine zentrale Frage beantworten müssen:

„Wie schneide ich eigentlich meine Aggregates?“


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Und plötzlich wird alles kompliziert. Sie merken, dass die Entscheidung, wo Sie Ihre Konsistenzgrenzen ziehen, gar nicht so einfach ist. Sie ist im Gegenteil sogar eine der schwierigsten Entscheidungen in einem Event-getriebenen System und gleichzeitig leider auch eine der folgenreichsten. In diesem Blogpost möchte ich Ihnen zeigen, warum das so ist, warum Aggregates problematisch sein können und was Sie dagegen beziehungsweise stattdessen tun können.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Dynamic Consistency Boundaries (DCB): Nie wieder Aggregates schneiden! // deutsch

Falls Sie mit Event-Sourcing noch nicht viel Erfahrung haben, empfehle ich Ihnen für den Einstieg zunächst das Video „Event-Sourcing – das einzige Video, das Du brauchst„. Dort erkläre ich Ihnen ausführlich, was Event-Sourcing überhaupt ist, wie es grundsätzlich funktioniert, wie man Events schreibt und sie nachher wieder liest, und warum das Ganze überhaupt sinnvoll ist.

Willkommen in der Stadtbibliothek!

Lassen Sie uns mit einem Beispiel beginnen – einem Beispiel, das ich inzwischen in vielen meiner Beiträge verwende, weil es einerseits einfach genug ist, um anschaulich und übersichtlich zu bleiben, und andererseits genug Komplexität bietet, um echte Probleme sichtbar zu machen. Die Rede ist von einer fiktiven Stadtbibliothek. Dort können Leserinnen und Leser Bücher ausleihen, sie bei Bedarf verlängern oder irgendwann (hoffentlich zumindest) zurückgeben. Es gibt außerdem Vormerkungen, Mahnungen und manchmal auch Strafen in Form von Gebühren, zum Beispiel, wenn etwas zu spät oder beschädigt zurückgegeben wird.

Natürlich gibt es auch Regeln, wie das Ganze ablaufen soll, beispielsweise:

„Eine Leserin oder ein Leser darf maximal drei Bücher gleichzeitig ausleihen.“

Oder:

„Ein Buch darf nur dann verlängert werden, wenn es nicht schon von jemand anderem vorgemerkt wurde.“

Das klingt zunächst recht einfach. Wenn Sie die Vorgaben jedoch in ein Event-basiertes System bringen möchten, werden Sie schnell merken: Die Umsetzung ist alles andere als trivial. Ein wesentlicher Grund dafür liegt in den Aggregates, die übrigens ironischerweise eigentlich gar nichts mit Event-Sourcing zu tun haben, da sie ursprünglich ein Konzept aus dem Domain-Driven Design (DDD) sind.

Aggregates sind transaktionale Konsistenzgrenzen

In DDD, und damit oft auch im Event-Sourcing, sind Aggregates die zentralen Konsistenzgrenzen. Sie kapseln Geschäftslogik, sie schützen Invarianten, sie garantieren, dass innerhalb ihrer Grenzen keine fachlich ungültigen Zustände entstehen können, und so weiter. Wenn Sie zum Beispiel ein Book-Aggregate haben, muss es sicherstellen, dass ein Buch nicht doppelt ausgeliehen werden kann oder nur dann zurückgegeben werden kann, wenn es vorher tatsächlich ausgeliehen wurde. Das klingt zunächst sinnvoll, und in vielen Fällen funktioniert es auch gut. Aber eben nicht immer. Aggregates haben ihren Preis. Wie es im Englischen so schön heißt: There is no free lunch.

Das Schneiden eines Aggregate ist eine weitreichende Entscheidung. Es bestimmt nicht nur, wo Konsistenz gilt, sondern auch, wie Sie Events strukturieren, wie Sie Commands modellieren, wie Sie dementsprechend Ihre APIs gestalten, wie Sie Ihre Event-Streams aufbauen, wie Sie diese speichern und wieder lesen. Kurz gesagt: Es bestimmt einen großen Teil Ihrer (Daten-)Architektur. Genau deshalb ist diese Entscheidung so wichtig – und gleichzeitig auch gefährlich.

Sie müssen sie nämlich sehr früh treffen, oft bevor Sie überhaupt genau wissen, wie Ihre Domäne im Detail funktioniert. Sie treffen also eine Entscheidung mit großer Tragweite auf der Basis von sehr wenig Wissen. Und sobald Sie sie einmal getroffen haben, wird es sehr schwierig, sie noch einmal zu revidieren.

Das Schlimmste an alldem: Aggregates sind keine isolierten Konzepte. Sie beeinflussen Ihr gesamtes System. Sie können sie nicht einfach umschneiden. Sie können sie nicht zur Laufzeit neu anordnen. Sie können sie nicht modular ersetzen wie einzelne Services oder Datenbanktabellen. Wenn Sie ein Aggregate falsch schneiden, zahlen Sie diesen Preis oft über Jahre.

Ein Beispiel aus der Praxis

Um das anschaulich zu machen, nehmen wir noch einmal das Beispiel aus der Bibliothek: Wir hatten gesagt, dass eine Leserin oder ein Leser maximal drei Bücher gleichzeitig ausgeliehen haben darf. Wenn Sie nun sagen

„Okay, dann mache ich einfach ein Reader-Aggregate“,

dann müssen Sie dort alle Ausleihen zusammenführen. Das bedeutet: Jedes Mal, wenn jemand ein Buch ausleihen möchte, müssen Sie alle bisherigen Ausleihen dieser Person kennen. Das wiederum bedeutet: Sie brauchen eine Event-Historie, die das abbildet – also einen Stream, der diese Informationen enthält. Doch was ist, wenn Sie stattdessen pro Ausleihe ein eigenes Aggregate haben wollen, also ein Loan-Aggregate?

Dann fehlt Ihnen plötzlich der Überblick: Sie wissen nicht, wie viele aktive Ausleihen es gibt, weil jede Ausleihe in einem eigenen Stream steckt. Sie müssten sie erst zusammenführen, was bei Event-Sourcing nicht trivial ist, da auf Event-Sourcing spezialisierte Datenbanken in der Regel keine Joins oder sonstige relationale Abfragen erlauben. Oder Sie entscheiden sich, das Buch als Aggregate zu modellieren. Dann steht die Regel aber völlig außerhalb des Kontexts dieses Aggregate, weil sie sich nicht auf ein einzelnes Buch, sondern auf die Summe der ausgeliehenen Bücher pro Leserin beziehungsweise pro Leser bezieht. Egal, wie Sie es schneiden – es passt nie so richtig.

Das Problem mit den Aggregates

Das eigentliche Problem: Aggregates sind statisch, viele Regeln sind in der Realität jedoch dynamisch. Aggregates sind strukturell, viele Geschäftsregeln dagegen semantisch. Aggregates orientieren sich an Objekten, viele Invarianten betreffen jedoch Beziehungen, Kombinationen oder Mengen. All das führt dazu, dass Sie Ihr Modell über kurz oder lang an die Struktur Ihrer Aggregate anpassen, statt Ihre Geschäftslogik so ausdrücken zu können, wie sie fachlich sinnvoll wäre.

Vielleicht war das früher weniger ein Problem. Solange Event-Sourcing ein Nischenthema für einige wenige war, konnte man sich mit komplexen Aggregates arrangieren. Das ändert sich jedoch derzeit. Event-Sourcing kommt langsam, aber stetig im Alltag an. Immer mehr Teams interessieren sich dafür, immer mehr Projekte setzen das Konzept produktiv ein. Websites wie CQRS.com und eventsourcing.ai oder Produkte wie EventSourcingDB (alle von the native web GmbH) tragen ihren Teil dazu bei. Doch je mehr Event-Sourcing in der Breite eingesetzt wird, desto mehr Menschen stoßen auf genau diese Fragen:

  • Wie schneide ich meine Aggregates?
  • Wie drücke ich Regeln aus, die sich nicht sauber in einem Objekt zusammenfassen lassen?
  • Wie gehe ich mit Konsistenz um, wenn mehrere Dinge zusammenhängen?

Kurz: Was lange als Randproblem galt, wird für viele Entwicklerinnen und Entwickler zur Alltagsfrage. Wir brauchen Lösungen, die dem gerecht werden.

Eventual statt Strong Consistency

Es kommt noch etwas hinzu: Manche Regeln betreffen nicht nur mehrere Entitäten, sondern sogar mehrere Aggregates. Dann wird es richtig kompliziert. Stellen Sie sich vor, jemand möchte ein Buch verlängern. Um zu prüfen, ob das erlaubt ist, müssen Sie wissen: Ist das Buch aktuell überhaupt ausgeliehen? Ist es von der richtigen Person ausgeliehen? Ist es noch nicht vorgemerkt? All diese Informationen liegen in unterschiedlichen Kontexten vor: Die Ausleihe ist eine Transaktion zwischen der Leserin oder dem Leser und dem Buch. Die Vormerkung ist ein separater Kontext: Sie hängt zwar am Buch, ist aber kein Teil der Ausleihe. Die maximale Anzahl an Verlängerungen kann je nach Bibliotheksregelung ebenfalls eine Rolle spielen. Versuchen Sie, das alles in ein einziges Aggregate zu pressen. Das geht in der Regel entweder gar nicht oder nur um den Preis enormer Komplexität.

Viele Systeme akzeptieren in solchen Fällen die sogenannte Eventual Consistency. Das heißt: Sie lassen die Verlängerung zunächst durchgehen und prüfen dann asynchron, ob die Operation tatsächlich gültig war. Wenn nicht, erzeugen sie ein Kompensations-Event, schicken eine Benachrichtigung oder markieren den Zustand als ungültig. Das funktioniert technisch, ist aber aus fachlicher Sicht unsauber. Sie modellieren damit keine echte Invariante mehr, sondern einen nachträglichen Reparaturmechanismus.

Ergänzend enthalten viele Systeme sogenannte Prozessmanager oder Sagas, die diese Prüfungen orchestrieren. Sie führen mehrere Streams zusammen, lesen parallele Zustände, berechnen Ergebnisse und entscheiden auf Basis von Zeitverhalten, Idempotenz und Zustandskombinationen. Auch das funktioniert, ist jedoch schwer zu durchschauen, zu testen und zu warten. Oft ist es ein völlig überdimensioniertes Konstrukt für eine fachlich eigentlich einfache Regel.

Kill the Aggregate!

Genau deshalb stellt sich die Frage: Geht das nicht auch anders? Kann man Konsistenz nicht so modellieren, wie man sie eigentlich denkt? Also nicht in Form eines Objekts, das alles weiß, sondern in Form einer Regel, die einfach prüft: Gilt das, was ich fachlich will? Genau das ist die Idee hinter Dynamic Consistency Boundaries (oder kurz DCBs).

Dieser Begriff wurde von der italienischen Informatikerin Sara Pellegrini geprägt, die in einem Vortrag mit dem Titel „Kill Aggregate!“ (nach einigen Minuten mit englischen Untertiteln) vor ein paar Jahren genau dieses Paradigma infrage gestellt hat: Muss Konsistenz wirklich immer an einem Objekt hängen? Oder geht es auch anders, nämlich dynamisch, operationsspezifisch und regelbasiert? Stellen Sie sich vor, Sie formulieren eine Regel nicht in Form eines Aggregate, sondern als direkte Bedingung auf die Event-Historie. Zum Beispiel:

„Zähle alle Events vom Typ bookLoaned, bei denen die Leser-ID 23 ist und für die noch kein bookReturned-Event existiert. Wenn die Anzahl kleiner als drei ist, ist die Operation erlaubt.“

Das ist alles. Keine Aggregates. Kein Slicing. Keine Refactoring-Hölle. Keine Joins. Keine Prozessmanager. Keine Sagas. Einfach nur eine Regel: direkt formuliert, direkt überprüft und direkt durchgesetzt. Das ist die Stärke von Dynamic Consistency Boundaries: Sie machen die Konsistenzprüfung zum Teil der Operation und nicht zum Teil der Struktur.

Voraussetzungen für DCBs

Damit das in der Praxis funktioniert, müssen einige Voraussetzungen erfüllt sein. Erstens benötigen Sie Zugriff auf alle relevanten Events. Sie müssen also in der Lage sein, bestimmte Event-Typen zu filtern, zum Beispiel alle bookLoaned-Events für eine bestimmte Nutzerin oder einen bestimmten Nutzer. Zweitens brauchen Sie die Möglichkeit, Bedingungen zu formulieren. Sie wollen etwas ausdrücken können wie:

„Wenn Bedingung X erfüllt ist, dann (und nur dann) schreibe Event Y.“

Drittens benötigen Sie ein System, das diese Bedingungen verlässlich prüft – serverseitig und atomar. Wenn Sie die Bedingungen im Anwendungscode prüfen und dann das Event schreiben, haben Sie wieder eine Race Condition. Diese drei Punkte zusammen bilden das Fundament für DCBs.

Genau das wird künftig zum Beispiel von der auf Event-Sourcing spezialisierten Datenbank EventSourcingDB unterstützt (die von meinem Unternehmen the native web entwickelt wird), und zwar über die eigens für EventSourcingDB entwickelte, deklarative Sprache EventQL. Sie können sich EventQL wie eine Art SQL vorstellen, nur für Events. Mit EventQL können Sie solche Regeln direkt formulieren und zukünftig beim Schreiben von Events in die EventSourcingDB als Vorbedingung angeben. Die Bedingung wird dann beim Schreiben des Events direkt im Server geprüft. Wenn sie erfüllt ist, wird das Event geschrieben. Wenn nicht, wird der Vorgang abgelehnt, und Sie können entsprechend reagieren. Das ist dann echte Konsistenz auf der Basis von realen Events – mit klaren Regeln, ohne Umwege.

Sie können damit Regeln abbilden, wie beispielsweise:

  • Ein Gutschein darf nur einmal eingelöst werden.
  • Ein Benutzername darf nicht doppelt vergeben sein.
  • Eine Anwenderin darf sich nur einmal mit demselben Token einloggen.
  • Eine Rechnung darf nur dann geschrieben werden, wenn der Auftrag abgeschlossen ist.
  • Ein Buch darf nur dann zurückgegeben werden, wenn es vorher tatsächlich ausgeliehen wurde.

Werden klassische Aggregates überflüssig?

All das sind Beispiele für Regeln, die sich schwer oder gar nicht mit klassischen Aggregates umsetzen lassen – zumindest nicht ohne großen Aufwand und Nebenwirkungen. Mit Dynamic Consistency Boundaries und EventQL werden sie hingegen trivial.

Das bedeutet nicht, dass Aggregates vollständig überflüssig werden. Es gibt nach wie vor viele Anwendungsfälle, in denen sie sinnvoll sind, insbesondere wenn Sie komplexe Zustandsübergänge modellieren oder interne Logik kapseln möchten. Sie benötigen sie jedoch nicht mehr zwingend für jede Regel. Das ist der entscheidende Punkt. Sie können jetzt wählen: Sie können fachliche Regeln direkt ausdrücken, so wie Sie sie verstehen, und entscheiden, ob Sie dafür wirklich ein Aggregate brauchen oder ob eine dynamische Konsistenzgrenze nicht vielleicht die bessere Wahl ist.


(rme)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

CNCF standardisiert KI-Infrastruktur mit neuem Kubernetes-Programm


Für viele Unternehmen lautet die zentrale Frage nicht mehr, ob sie künstliche Intelligenz einsetzen, sondern wie sie diese verantwortungsvoll und nachhaltig integrieren. Bislang bremsen fragmentierte, nicht standardisierte Insellösungen und meist teure proprietäre KI-Stacks die Einführung noch. Besonders für Organisationen, die auf Datensouveränität, Compliance und langfristige finanzielle Stabilität setzen, stellt die unkoordinierte KI-Infrastruktur ein erhebliches Risiko dar – in Hybrid-Cloud-Umgebungen ebenso wie On-Premises.

Weiterlesen nach der Anzeige

Mit der im Rahmen der KubeCon + CloudNativeCon North America 2025 offiziell freigegebenen Version 1.0 des „Kubernetes AI Conformance“-Programms will die Cloud Native Computing Foundation (CNCF) nun Ordnung in die zersplitterte KI-Landschaft bringen. Das Programm geht dabei über eine Zertifizierung hinaus – es ist als eine weltweit getragene Open-Source-Initiative angelegt, die einen gemeinsamen technischen Standard für KI-Infrastrukturen schaffen soll. „Insbesondere für europäische Unternehmen liefert sie den Rahmen, um KI sicher und skalierbar einzusetzen“, erklärt Mario Fahlandt, der bei der CNCF unter anderem als Co-Chair der Technical Advisory Group (TAG) Operational Resilience sowie der Special Interest Group (SIG) Contributor Experience für Kubernetes aktiv ist. „Die Initiative definiert eine klare, zukunftssichere Roadmap, die Workload‑Portabilität, technische Konsistenz und digitale Souveränität gewährleistet.“

Technische Standards versus Prozess‑Frameworks

Während der KI-Markt durch eine Vielzahl an Zertifizierungen geprägt ist, müssen Entscheidungsträger klar zwischen technischen und organisatorischen Standards unterscheiden. Einige Anbieter konzentrieren sich auf Management- und Governance-Frameworks wie ISO 42001. Dieser internationale Standard legt Anforderungen für den Aufbau eines KI-Managementsystems (AIMS) fest. Er unterstützt Unternehmen dabei, Risiken, ethische Fragen, Datenschutz und regulatorische Vorgaben zu steuern. Außerdem bewertet er, ob interne Prozesse eine verantwortungsvolle Entwicklung und Bereitstellung von KI sicherstellen.

Das neue CNCF‑Programm „Kubernetes AI Conformance“ hebt sich grundlegend von Governance-Standards ab. Es fungiert primär als technischer Implementierungsstandard und legt dazu fest, welche Fähigkeiten, APIs und Konfigurationen ein Kubernetes-Cluster benötigt, um KI‑ und ML‑Workloads zuverlässig und effizient auszuführen. Damit zielt die CNCF-Konformität auf eine garantierte technische Portabilität ab, die auch zu weniger Abhängigkeit von einzelnen Herstellern beiträgt. Sie stellt sicher, dass Unternehmen ihre KI-Anwendungen künftig auf jeder konformen Plattform betreiben können – in der Public Cloud, im eigenen Rechenzentrum oder an Edge-Standorten. Diese Portabilität bildet die Grundlage digitaler und damit auch datengetriebener Souveränität.

Die Entwicklung des Standards treibt innerhalb des Kubernetes-Projekts eine neu gebildete Arbeitsgruppe voran, die durch die Special Interest Groups Architecture und Testing unterstützt wird. Seit der KubeCon Europe im Frühjahr 2025 hat die Gruppe zunächst zentrale technische Säulen definiert, die die besonderen Anforderungen von KI‑Workloads berücksichtigen. „Darauf aufbauend entstand ein verbindlicher Anforderungskatalog, den jede Plattform erfüllen muss, um als Kubernetes-AI-konform zu gelten“, erläutert Fahlandt.

Weiterlesen nach der Anzeige

Effizientes Management von Beschleunigern im KI-Training

KI‑Trainingsjobs setzen umfassende Hardware‑Ressourcen voraus und benötigen meist teure, häufig zudem knapp verfügbare GPUs. In nicht standardisierten Umgebungen ergeben sich daraus zwei Kernprobleme:

  • Ressourcenfragmentierung: Wertvoller GPU‑Speicher bleibt ungenutzt.
  • Topologie‑Blindheit: Das Scheduling ist nicht für Multi‑GPU‑Workloads optimiert.

Beide Aspekte tragen zur Überprovisionierung und steigenden Kosten bei.

Eine CNCF‑konforme Plattform muss daher die Kubernetes-API für Dynamic Resource Allocation (DRA) unterstützen. Seit Kubernetes-Version 1.34 gilt DRA als stabil und ermöglicht es, komplexe Hardware-Ressourcen flexibel anzufordern und zu teilen. Ähnlich dem PersistentVolumeClaim‑Modell für Speicher können Nutzerinnen und Nutzer gezielt Ressourcen aus definierten Geräteklassen anfordern. Kubernetes übernimmt dabei automatisch das Scheduling und die Platzierung aller Workloads.

Erweiterte Ingress‑Funktionen für KI-Inferenz

KI‑Inferenz‑Workloads – also KI-Modelle im Betrieb – unterscheiden sich stark von typischen, zustandslosen Webanwendungen. Sie laufen meist länger, beanspruchen viele Ressourcen und speichern Zustände. Standard‑Load‑Balancer sind für deren Lastverteilung ungeeignet. Das CNCF‑Konformitätsprogramm verlangt daher die Unterstützung der Kubernetes Gateway API und ihrer Erweiterungen für modellbewusstes Routing (model‑aware routing).

Die Gateway API Inference Extension, ein offizielles Kubernetes‑Projekt, erweitert Standard-Gateways zu spezialisierten Inference‑Gateways. Damit lassen sich Routing und Load Balancing gezielt für KI‑Workloads optimieren. Unterstützte Funktionen sind unter anderem gewichtete Verkehrsaufteilung (weighted traffic splitting) und Header‑basiertes Routing, das etwa für OpenAI-Protokoll‐Header relevant ist.

Zeitplanung und Orchestrierung von KI‑Workloads

Verteilte KI-Trainingsjobs bestehen aus mehreren Komponenten, die gleichzeitig starten müssen. Plant der Scheduler Pods einzeln ein, kann es zu Deadlocks kommen: Ein Job bleibt hängen, weil einige Pods keine Ressourcen finden, andere aber bereits Ressourcen blockieren. Eine Kubernetes-Plattform muss mindestens eine All‑or‑Nothing‑Scheduling‑Lösung unterstützen, beispielsweise Kueue oder Volcano. So starten verteilte KI‑Workloads nur, wenn alle zugehörigen Pods gleichzeitig platziert werden können.

Ist ein Cluster‑Autoscaler aktiv, soll er Knotengruppen mit bestimmten Beschleunigertypen je nach Bedarf automatisch vergrößern oder verkleinern. Ebenso muss der HorizontalPodAutoscaler Beschleuniger‑Pods korrekt skalieren und dabei auch benutzerdefinierte Metriken berücksichtigen, die für KI‑ und ML‑Workloads relevant sind.

Überwachung und Metriken

Moderne KI‑Workloads und spezialisierte Hardware erzeugen neue Lücken im Monitoring. Noch fehlt ein einheitlicher Standard, um Beschleuniger-Metriken zu erfassen – viele Teams verfügen daher nicht über geeignete Werkzeuge, um Infrastrukturprobleme schnell zu analysieren.

Jede CNCF‑konforme Plattform muss daher künftig eine Anwendung installieren können, die Leistungsmetriken für alle unterstützten Beschleunigertypen – etwa Auslastung oder Speichernutzung – über einen standardisierten Endpunkt verfügbar macht. Zusätzlich ist ein Überwachungssystem erforderlich, das Metriken automatisch erfasst und verarbeitet, wenn Workloads sie im Standardformat (z. B. Prometheus‑Expositionsformat) bereitstellen.

Sicherheit und Ressourcentrennung

Beschleuniger wie GPUs sind gemeinsam genutzte Ressourcen. Fehlt eine strikte Isolierung auf Kernel‑ und API-Ebene, können Container‑Workloads gegenseitig auf Daten oder Prozesse zugreifen und so Sicherheitsrisiken in Multi‑Tenant‑Umgebungen verursachen. Eine CNCF‑konforme Plattform muss daher den Zugriff auf Beschleuniger klar trennen und über Frameworks wie Dynamic Resource Allocation (DRA) oder Geräte-Plug-ins kontrollieren. Nur so lassen sich Workloads isolieren und unerlaubte Zugriffe oder Beeinträchtigungen verhindern.

Unterstützung für Operatoren

KI-Frameworks wie Ray oder Kubeflow sind verteilte Systeme, die auf Kubernetes als Operatoren laufen. Eine Plattform benötigt dafür eine stabile Basis, um zu verhindern, dass instabile Webhooks, CRD‑Verwaltung (Custom Resource Definition) oder eine unzuverlässige API-Server-Struktur dazu führen, dass Operatoren ausfallen und die gesamte KI-Plattform zum Stillstand kommt.

Eine CNCF-konforme Umgebung muss mindestens einen komplexen KI-Operator (etwa Ray oder Kubeflow) installieren und ausführen können. Sie muss nachweisen, dass Operator‑Pods, Webhooks und die Reconciliation der Custom Resources stabil und vollständig funktionieren.

Ein internationaler, Community‑getriebener Standard mit europäischer Beteiligung

Das Kubernetes-AI-Conformance‑Programm der CNCF schafft auf Basis der von der Arbeitsgruppe WG AI Conformance definierten Säulen einen stabilen, offenen und zukunftssicheren Standard für KI-Infrastrukturen. Plattformen, die auf den offenen Upstream-APIs basieren, eröffnen insbesondere auch europäischen Unternehmen die Chance, ihre KI-Strategien portabel und souverän umzusetzen – von der Public Cloud bis zum sicheren On‑Premises‑Rechenzentrum. „Verschiedene Anbieter‑Plattformen sind bereits ‚Kubernetes AI Conformant‘ für die Kubernetes-Versionen 1.33 und 1.34“, sagt Fahlandt. Dazu zählen auch Plattformen europäischer Anbieter wie Gardener, Giant Swarm, Kubermatic und SUSE.

Weitere Anforderungen werden laufend entwickelt und im Community‑Prozess diskutiert. Die CNCF lädt alle Interessierten ein, sich aktiv an dem offenen Standard zu beteiligen. Weitergehende Informationen rund um das Programm finden sich in der offiziellen Ankündigung im CNCF-Blog.


(map)



Source link

Weiterlesen

Entwicklung & Code

fish 4.2.0: Mehrzeilige Befehle und UTF-8 als Standard


Die Entwickler der Shell fish haben Version 4.2.0 veröffentlicht. Zu den wichtigsten Neuerungen zählen mehrzeilige Befehle in der verlaufsbasierten Autovervollständigung sowie grundlegende Änderungen bei der Zeichenkodierung.

Weiterlesen nach der Anzeige

Die Autovervollständigung auf Basis der Befehlshistorie schlägt nun auch mehrzeilige Kommandos vor – eine Funktion, die bei komplexeren Shell-Skripten oder verschachtelten Befehlen für viele Nutzer im Alltag praktisch ist. Zudem wurden Probleme beim Löschen mehrzeiliger transienter Prompts behoben: Wenn ein solcher Prompt mehr Zeilen umfasst als der finale Prompt, wird er jetzt korrekt entfernt.

Ein weiteres praktisches Feature betrifft die Terminal-Konfiguration: Anwender können jetzt den Titel des Terminal-Tabs getrennt vom Fenstertitel setzen, indem sie die Funktion fish_tab_title definieren – gut für den Überblick. Bei sehr langen Kommandozeilen blendet fish außerdem den Teil des mehrzeiligen Prompts aus, der aufgrund der Bildlaufposition nicht mehr sichtbar ist. Das verhindert doppelte Zeilen nach dem Neuzeichnen.

UTF-8 jetzt vorausgesetzt

Eine grundlegende Änderung betrifft die Zeichenkodierung: fish geht jetzt immer von UTF-8 aus, selbst wenn das System kein UTF-8-Locale konfiguriert hat. Eingabebytes, die kein gültiges UTF-8 darstellen, werden weiterhin korrekt verarbeitet – Dateipfade mit veralteten Kodierungen lassen sich also nach wie vor verwenden, werden aber möglicherweise anders auf der Kommandozeile dargestellt. Auf Systemen ohne Multi-Byte-Locale verzichtet fish künftig auf ASCII-Ersatzzeichen für Unicode-Symbole wie das Auslassungszeichen.

Die Mausbedienung wurde flexibler: fish deaktiviert nicht mehr zwangsweise die Mauserfassung (DECSET/DECRST 1000), sodass Nutzer per Mausklick den Cursor bewegen oder Vervollständigungsvorschläge auswählen können. Die Tastenkombination alt-p fügt zudem kein überflüssiges Leerzeichen mehr zur Kommandozeile hinzu.

Standalone-Build nun Standard

Weiterlesen nach der Anzeige

Für Distributoren und Entwickler ist relevant, dass der Standalone-Build-Modus jetzt standardmäßig aktiv ist. Die Dateien in $CMAKE_INSTALL_PREFIX/share/fish werden künftig nicht mehr verwendet – mit Ausnahme der HTML-Dokumentation. Dadurch brechen künftige Updates laufende Shells nicht mehr ab, wenn sich interne Hilfsfunktionen geändert haben. Die Datendateien werden vorerst redundant installiert, um bereits laufende Shells zu schützen. Die minimale unterstützte Rust-Version wurde auf 1.85 geändert.

Release-Tags und Quellcode-Archive sind nun wieder GPG-signiert. Die Dokumentation in den Release-Paketen wird jetzt mit der aktuellen Sphinx-Version erstellt, wodurch die vorgenerierten Man-Pages OSC-8-Hyperlinks enthalten. Die Sphinx-Abhängigkeit ist jetzt in pyproject.toml spezifiziert, wodurch Nutzer uv für den Dokumentations-Build einsetzen können.

Plattform-spezifische Verbesserungen

Unter macOS setzt fish als Login-Shell die Variable MANPATH nun korrekt, wenn diese bereits in der Umgebung vorhanden war. Ein Windows-spezifisches Problem, bei dem die webbasierte Konfiguration nicht startete, wurde ebenfalls behoben. Für MSYS2 gibt es einen Workaround für Konsole und WezTerm, der verhindert, dass diese das falsche Arbeitsverzeichnis beim Öffnen neuer Tabs verwenden.

Im Rahmen der Version 4.0, die im Februar 2025 erschien, hatten die fish-Entwickler den Kerncode von C++ nach Rust portiert. Release 4.2.0 behebt mehrere Regressionen aus den Vorgängerversionen 4.0.0 und 4.1.0, darunter Probleme mit der webbasierten Konfiguration unter Python 3.9, falsche Terminal-Modi bei bestimmten Kommandos und Fehler beim Speichern universeller Variablen unter MSYS2. Auch VTE-basierte Terminals zeigen beim Ändern der Fenstergröße wieder das korrekte Verhalten.

Schließlich wurden auch die Übersetzungen erweitert: Neben den bereits vorhandenen Sprachen ist nun Chinesisch (Taiwan) mit an Bord, zudem wurden die französischen Übersetzungen ergänzt. Die Release Notes auf GitHub listen alle Änderungen detailliert auf. Für Linux stehen Standalone-Binaries für verschiedene CPU-Architekturen bereit, macOS-Pakete können über Homebrew bezogen werden. Windows-10- und -11-Nutzer müssen das Windows Subsystem for Linux (WSL) heranziehen, darüber hinaus lässt sich fish mit Cygwin und MSYS2 verwenden.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Schadsoftware weiter aktiv: GlassWorm erneut in Open-VSX-Paketen gefunden


Der Mitte Oktober entdeckte Supply-Chain-Angriff über die Marktplätze von Visual Studio Code geht offenbar weiter: Auf dem Open-VSX-Marktplatz der Eclipse Foundation sind drei weitere Pakete mit GlassWorm aufgetaucht.

Weiterlesen nach der Anzeige

Die Pakete setzen auf dieselben Verschleierungstechniken und nutzen dieselben Angriffsmuster wie die im Oktober gefundenen Packages. Kurz nach dem Bekanntwerden des Angriffs hatte die Eclipse Foundation ihn offiziell als abgeschlossen erklärt und zusätzliche Sicherheitsmaßnahmen angekündigt.

Die drei Anfang November gefundenen Pakete ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge und yasuyuky.transient-emacs kommen laut dem Security-Unternehmen Koi gemeinsam auf knapp 10.000 Downloads.

Wiederum setzt der Angriff auf die Solana-Blockchain und verwendet Folgen von Unicode-Zeichen, die viele Editoren nicht anzeigen. Auch auf GitHub finden sich Hinweise auf Schadsoftware mit denselben Mustern.

Der unsichtbare Glaswurm

Den Namen GlassWorm hatte Koi der Schadsoftware im Oktober gegeben, da sie zum einen im Editor unsichtbar ist und sich zum anderen selbst vermehren soll – ähnlich wie die im September auf npm gefundene Schadsoftware Shai Hulud.

Allerdings vermehrt der GlassWorm sich nicht eigenständig, sondern greift lediglich Credentials unter anderem zu GitHub ab, die die Angreifer vermutlich mit KI-Unterstützung nutzen, um die Schadsoftware zu verteilen.

Die Malware enthält nicht nur wie üblich verschleierten Code, sondern setzt auf Unicode-Zeichen, die im Editor nicht sinnvoll darstellbar sind – und daher oft überhaupt nicht dargestellt werden. Dafür verwendet sie Folgen von Unicode-Variantenselektoren. Das Resultat ist für menschliche Reviewer unsichtbar. Diff-Betrachter und ähnliche Tools zeigen die eigentlichen Unterschiede ebenfalls nicht an, weisen aber darauf hin, dass Unterschiede bestehen. Hinzu kommt, dass ein kleines Codestück sichtbar sein muss, um den restlichen, versteckten Code zu dekodieren und auszuführen.

Weiterlesen nach der Anzeige

Blockchain für die C2-Infrastruktur

Dank der Solana-Blockchain ist die Infrastruktur für die Command-and-Control-Server resilient gegen das Abschalten einzelner Server. Die Schadsoftware besorgt sich über die öffentliche Blockchain Links im Base64-Format auf den Payload mit der eigentlichen Schadsoftware.

Auf die Weise können die Angreifer jederzeit den C2-Server austauschen und die neue Adresse über die Blockchain veröffentlichen.

Auch auf GitHub aktiv

Der GlassWorm ist laut dem Koi-Blog nun auch auf GitHub aufgetaucht. Maintainer haben gemeldet, dass ihre Repositories vermutlich KI-generierte, auf den ersten Blick zum Projekt passende und legitime Commits erhalten haben, die Code mit den Angriffsmustern von GlassWorm enthalten, der ebenfalls unsichtbar ist.

Im Blogbeitrag heißt es, dass die Commits auf GitHub Private Use Areas nutzen, also für den eigenen Gebrauch ausgewiesene Unicode-Zeichen. Damit soll der Code ebenfalls unsichtbar werden, was wir aber in eigenen Versuchen nicht nachvollziehen konnten.

Russische Gruppe hinter den Angriffen vermutet

Laut dem Koi-Blog haben die Angreifer nach einem Tipp eines Security-Forschers, der anonym bleiben will, einen Endpunkt auf ihrem Server ungesichert gelassen. Koi hat die Lücke genutzt, um Daten auszulesen.

Dort fanden sie Informationen zu den vom Angriff betroffenen Unternehmen und Organisationen, darunter eine staatliche Einrichtung aus dem Nahen Osten.



Die Daten enthalten russische Texte und einen Verweis auf RedExt.

(Bild: Koi)

Interessanterweise waren laut Koi auch Keylogger-Daten des Angreifers in den Daten zu finden. Aus ihnen lässt sich unter anderem ablesen, dass die Angreifer Russisch sprechen und das Command-and-Control-Framework RedExt verwenden.

Koi hat die Informationen an die Strafverfolgungsbehörden weitergegeben, um die Opfer zu informieren und gegen die Angreifer vorzugehen.


(rme)



Source link

Weiterlesen

Beliebt