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

KI Navigator #12: Ist das Kunst oder kann das KI-Bild weg?


Willkommen zur zwölften Ausgabe der KI-Navigator-Kolumne der DOAG KI Community!


Kolumne KI-Navigator – Verena Barth

Kolumne KI-Navigator – Verena Barth

Verena Barth setzt sich als Expertin und Speakerin im Bereich Explainable AI (XAI) leidenschaftlich für ethische KI und die Verständlichkeit von komplexen ML-Systemen ein, um eine nachvollziehbare und gewissenhafte Anwendung zu ermöglichen. In industriellen ML-Projekten war sie als IT-Consultant im Bereich Data Science und MLOps tätig, bevor sie 2024 “Business Buddy AI” mitgründete, das personalisiertes Business Coaching mithilfe von affektiver KI skalierbar anbietet.

Neulich zeigte mein Bruder mir eine Illustration eines Sonnenuntergangs am Strand, die angeblich komplett von einer Maschine gemacht wurde. Ein interessanter Stil, eine surreale Landschaft, leuchtende Farben, fantastische Details. Mein erster Impuls: Staunen. Mein zweiter: Skepsis.

Kann KI Kunst? Ein heißes Thema, zu dem ich meinen metaphorischen Senf dazugeben möchte – nicht als neutrale Beobachterin, sondern als jemand, der mitten im Spannungsfeld steht: Ich bin KI-Expertin und Künstlerin.

In Gesprächen mit Kunstschaffenden weltweit begegnen mir immer wieder dieselben Ängste bezüglich KI: kopiert, ausgebeutet und ersetzt zu werden. Was folgt, ist meine persönliche Sicht – subjektiv, ehrlich und frei von akademischem Kunst- oder Philosophieballast.

Was ist Kunst – und wer darf sie machen?

Laut Wikipedia ist Kunst ein kulturelles Ausdrucksmittel des Menschen, das Ergebnisse kreativer Prozesse in Form von Werken hervorbringt, die nicht primär durch Funktionalität, sondern durch Ausdruck, Gestaltung und Bedeutung geprägt sind. Tatsächlich war ich überrascht, wie oft und explizit darauf hingewiesen wird, dass sie aus einer menschlichen Tätigkeit/Arbeit resultiert. Das dient nicht der Differenzierung zwischen Mensch und KI (die auch ein Produkt menschlicher Arbeit ist), sondern zur Natur (natürlich – künstlich).




(Bild: DOAG)

Die Konferenz KI Navigator zeigt am 19. und 20. November in Nürnberg die konkrete Anwendung von KI in den Bereichen IT, Wirtschaft und Gesellschaft. Die von DOAG, heise conferences und de’ge’pol ausgerichtete Veranstaltung bietet gut 100 Sessions in sechs Tracks. Bis zum 1. Oktober sind Tickets zum vergünstigten Frühbucherpreis von 990 Euro (zzgl. MwSt.) verfügbar.

Hier beziehe ich mich auf den enger gefassten Begriff von Kunst im Sinne der sogenannten schönen Künste, primär die Bildende Kunst, nicht auf die Kunst als Handwerk, Technik, Wissen oder bloße Fertigkeit.

Die Kunst wandelt sich mit der Zeit. Sie spiegelt Gesellschaft, Geschichte und Identität, reagiert auf Umbrüche, stellt Fragen und erfindet sich immer wieder neu. Wenn Kunst ein sich ständig veränderndes kulturelles Ausdrucksmittel ist und mit der Zeit geht, warum sollte sie dann nicht auch durch neue Werkzeuge oder gar neue Akteure entstehen? Die zentrale Frage, die sich mir und vielen anderen stellt: Darf etwas als Kunst gelten, das kein fühlender Mensch erschaffen hat?

Zwischen Impulsgeber und Identitätsdiebstahl

Natürlich kann man KI als weiteres kreatives Tool wie Photoshop oder die Kamera sehen. Künstlerinnen oder Künstler geben Prompts ein, wählen aus, verfeinern. Doch generative KI geht weiter: Sie schlägt selbst vor – gelernt von Millionen Bildern und Stilen, ohne Rücksicht auf Grenzen zwischen Inspiration und (urheberrechtsverletzender) Kopie.

Neulich habe ich mit einer Kundin ChatGPT zur Ideenfindung und für das Generieren von Referenzbildern verwendet. Dabei habe ich überraschend inspirierende Impulse erhalten. Ersetzt hat mich das in diesem Fall zwar nicht, aber es hat mir gezeigt, wie viel Zeitersparnis KI bei konzeptioneller Arbeit bringen kann, etwa bei der Suche nach Referenzbildern mit korrekter Perspektive oder gewünschter Lichtführung.

Wenn KI Routineaufgaben und Generisches übernimmt, bleibt mehr Raum für das Echte, Spontane, Spaßige, Unvollkommene – das, was keine Maschine nachbilden kann. Trotzdem habe ich Hemmungen, ihr meine eigenen Werke anzuvertrauen. Ich fürchte, meinen Stil zu verlieren – das, was mich ausmacht. Theoretisch könnte jemand mithilfe weniger Bilder ein Werk in meinem Stil erzeugen, ohne dass ich es je erfahre oder dafür (zumindest mit Anerkennung) entlohnt werde. Ein kostengünstiges, effizientes, aber leeres Echo meiner Arbeit.

Es fehlt das Erlebnis, das Ringen mit der Idee, die Emotionen – das Menschliche. Reicht technische Raffinesse und cleveres Kombinieren, oder braucht es für echte Kunst einen fühlenden Menschen als Schöpfer?

Kann KI fühlen – und muss sie das überhaupt?

Um einen großen Aufschrei zu vermeiden: KI kann nicht fühlen, aber sie imitiert meisterhaft. Für viele lebt Kunst vom Ausdruck, dem Prozess, dem Kontext und der Intention der Kunstschaffenden – nicht nur von Form und Ästhetik. Deshalb beeinflusst der Name der Künstlerin oder des Künstlers den Preis eines Werks oft mehr als die Ausdruckskraft des Bildes. In dieser Hinsicht bleiben KI-Werke oberflächlich und letztlich auch gefühllos.

Allerdings ist diese Ansicht auch das, was Kunst teilweise elitär macht und viele meiner nicht kunstaffinen Freunde abstößt: Weil sie glauben, es gäbe die eine richtige Deutung oder Interpretation, weil abstrakte Werke oft unzugänglich wirken und weil Kunst zu oft in komplizierten Worten statt in echten Gefühlen vermittelt wird.

Auch wenn die Einschätzung eines Bildes mit Kenntnis der Künstlerbiografie vielleicht anders ausfallen würde, darf man dennoch seine eigene Wahrnehmung ernst nehmen und sich einfach fragen: „Was sehe ich? Was fühle ich? Und warum?“

Persönliches Fazit: Kann KI Kunst?

Was KI kann, liegt nicht nur in ihr, sondern auch in dem, was wir in ihr sehen – oder sehen wollen.

Wenn wir Kunst allein als Ergebnis eines kreativen Prozesses betrachten – als Werk mit Ausdruck, Form und Wirkung – dann kann KI Kunst erzeugen. Beeindruckend, effizient und manchmal sogar berührend. Doch sobald wir Kunst als bewusste, intentionale Handlung verstehen – als Ausdruck von Erfahrung, Identität, Haltung – stoßen wir an eine Grenze: KI bietet kein Wollen, kein Fühlen, kein echtes Bewusstsein.

Und trotzdem kann sie Bedeutung erzeugen. Nicht aus sich selbst heraus, sondern durch den Menschen, der mit ihr interagiert. Sie kann nicht begreifen, aber berühren. Keine Absicht haben, aber inspirieren.

Vielleicht liegt genau darin die neue Rolle der Kunst: Nicht in der Frage, ob etwas Kunst ist, sondern im menschlichen Blick darauf, in dem, was wir daraus machen. In Zeiten von KI liegt die Kunst vielleicht nicht mehr nur im bewussten Produzieren, sondern im bewussten Konsumieren: im Erkennen, im Reagieren, im In-Beziehung-Treten. Der Mensch als fühlender, bedeutungsgebender und denkender Bezugspunkt bleibt dann immer noch das Subjekt der Kunst – nicht die Maschine.


(rme)



Source link

Weiterlesen

Entwicklung & Code

Von Bitnami müssen wir uns allerdings verabschieden


Ende August werden große Teile des Bitnami-Katalogs kostenpflichtig und über Arrow teuer vermarktet. Kunden befürchten Kosten von 50.000 US-Dollar im Jahr und mehr. Die jetzige Sammlung wandert in einen Legacy-Katalog, den Broadcom aber nicht mehr pflegen wird. Anwenderinnen und Anwender müssen nach Alternativen suchen.


Johannes Kleinlercher

Johannes Kleinlercher

Johannes Kleinlercher ist Senior Cloud-Native Platform Engineer bei der Firma suXess-it in Österreich und berät gerne Kunden im Bereich Kubernetes, Cloud-Native und Platform-Engineering. Mit der Internal Developer Platform Distribution kubriX bietet suXess-it eine Out-Of-The-Box IDP auf Basis von Kubernetes an, um schnell und unkompliziert eigene Self-Service-Plattformen aufzubauen.

heise developer spricht mit dem Cloud-native-Experten Johannes Kleinlercher darüber, wie Anwender sich behelfen können, welche Alternativen es gibt und welche Perspektiven sich für die Open-Source-Community ergeben.

Manche Images und Charts bleiben bei Bitnami ja offen. Aber welche für Developer wichtigen hat Broadcom konkret hinter die Paywall geschoben?

Welche Bitnami-Images weiterhin offen bleiben, sieht man jetzt schon vorab unter https://hub.docker.com/u/bitnamisecure. Für Helm-Charts ist das hingegen gar nicht so leicht offiziell herauszufinden. Bitnami erwähnt nur das populäre Chart sealed-secrets. Das heißt, man muss davon ausgehen, dass mehr oder weniger alle anderen nicht mehr frei zur Verfügung stehen.

Der Sourcecode der Helm-Charts bleibt allerdings unter der Apache-2.0-Lizenz frei zur Verfügung, nur die gebauten und versionierten OCI-Artefakte verschwinden hinter der Paywall. Um herauszufinden, welche Images ein Helm-Chart heranziehen, empfehle ich das Plug-in helm-images. Und um alle transitiven Abhängigkeiten von Helm-Charts ausgeben zu lassen, das Plugin helm cascade.

In meiner Firma suXess-it verwendeten wir bis vor Kurzem für die Internal Developer Platform kubriX die Charts von Keycloak und PostgreSQL. Gerade das Keycloak-Chart von Bitnami ist bei sehr vielen Entwicklerinnen und Entwicklern beliebt, weil das offizielle Keycloak-Projekt zwar einen Operator für Kubernetes zur Verfügung stellt, aber kein Helm-Chart für diesen oder für eine klassische Keycloak-Installation.

Aber auch bei anderen Applikationen wie Kafka findet man bei einer Suche an erster Stelle immer das Bitnami-Chart. Bitnami hat in seinem Repository 118 Helm-Charts, wie ArgoCD, verschiedene Grafana-Projekte, Nginx, RabbitMQ, Kafka, Gitea, WildFly, Tomcat, WordPress und so weiter. Alle 118 sind je nach Branche mehr oder weniger populär. Viele Firmen verlassen sich auf Bitnami-Charts und -Images, weil sie sehr gut gehärtet und laufend aktualisiert werden.

Welche Folgen ergeben sich für die Projekte, die auf Bitnami bauen?

Die müssen nun aufpassen, ob nicht Helm-Charts als Abhängigkeit – auch indirekte – irgendwo auf ein Bitnami-Chart verweisen, ohne es wirklich zu wissen. Sehr spannend ist auch, dass populäre Helm-Charts wie Kyverno und Velero immer noch in ihrer aktuellsten Version das kubectl-Image von Bitnami integrieren und erst neue Releases herausbringen müssen, wo sie auf Alternativen umstellen, wie die beiden Issues von Kyverno und Velero zeigen. Vermutlich gibt es noch einige andere Charts, die ähnliche Themen haben.

Durch die Umstellung von Broadcom können also tatsächlich viele Probleme entstehen. Ich sehe den Vorfall auch als Weckruf, sich mehr um die Cloud-native Supply Chain zu kümmern und nicht unbedacht Charts oder Images in Projekte zu integrieren. Wichtig ist, die Abhängigkeiten zu verstehen und ordentlich zu managen.

Wie stark ist die Abhängigkeit der Entwicklungs-Branche von Bitnami? Können die Nutzer als Konsequenz einfach auf andere Anbieter umsteigen oder selbst etwas aufsetzen?

Wie bereits erwähnt, nutzten viele Personen oder Firmen in der Vergangenheit Bitnami-Images oder -Charts, weil sie sehr sicher und aktuell gehalten wurden. Dafür muss man sich bei Bitnami bedanken, aber auch bei allen freiwilligen, externen Contributoren, die dazu beigetragen haben.

Bei einigen Charts wie Keycloak gab es auch gar keine Alternative. Ich schätze die generelle Abhängigkeit in der Industrie deshalb als sehr hoch ein. In meiner Firma haben wir mit Keycloak die Erfahrung gemacht, dass wir nicht ohne Weiteres auf einen anderen Anbieter umsteigen können oder sollten. Wenn man irgendwo im Internet eine Alternative findet, muss man sich viele Fragen stellen:

  • Wie sicher und vertrauenswürdig ist die Quelle?
  • Welche Maintainer stecken dahinter?
  • Unter welcher Lizenz wird das Chart oder das Image angeboten?
  • Wann wurde das Projekt das letzte Mal aktualisiert?
  • Entspricht der Code gängigen Security-Best-Practices?

Natürlich kann man auch immer selbst die Images und Helm-Charts pflegen, aber bei Software, die sich laufend weiterentwickelt, darf man den Wartungsaufwand nicht unterschätzen. Auch die Frage „Was muss ich für die neue Keycloak-Version im Dockerfile oder Helm-Chart anpassen?“ stellt sich dann laufend. Aus diesem Grund entstehen oft Open-Source-Projekte. Nicht weil alles gratis ist, sondern weil man gemeinsam einen Mehrwert für viele schafft, der sonst für einzelne fast unmöglich zu erarbeiten wäre.

Es gibt auch gute Gründe, keine Charts aus der Community zu verwenden. Wenn eine Firma zum Beispiel komplett unabhängig sein will oder eine konkret auf die eigene Umgebung abgestimmte Lösung benötigt.

Für Keycloak gibt es ja erste Überlegungen, eine Alternative ins Leben zu rufen. Wie reagiert die Open-Source-Community auf die neue Paywall?

Für uns in der Firma war klar, dass wir eine nachhaltige Lösung für uns, aber auch für die Community suchen wollen. Ich habe deshalb über LinkedIn und Github-Issues in den jeweiligen Projekten versucht, gemeinsam mit der Community mögliche Alternativen zu finden. Es hat sich herausgestellt, dass die beste Alternative wäre, ein Helm-Chart so nahe wie möglich bei den Keycloak-Maintainern zu entwickeln. Das steigert den Wert des Projekts selbst und macht auch eine halbwegs effiziente Wartung möglich.

Einige Keycloak-Maintainer und -Contributoren stehen dem auch sehr offen gegenüber, wenngleich auch deren Kapazitäten knapp sind. Es geht jetzt also darum, das Ganze wirklich als Gemeinschaftsprojekt zu sehen, und nicht einfach jemandem die Aufgabe zu übergeben und dann nur zu konsumieren. Ob sich das bis zur Einführung der Paywall am 28. August noch ausgeht, steht leider noch nicht fest.

Was können Keycloak-Anwender jetzt tun?

Derzeit empfehle ich allen, die jeweiligen Kubernetes-Manifeste des Keycloak-Operators in der passenden Version ins eigene Helm-Chart zu integrieren und eine eigene Keycloak-CustomResource zu definieren. Wenn eine neue Version des Keycloak-Operators erscheint, muss man entsprechend die Kubernetes-Manifeste aus dem oben erwähnten Git-Repository beim neuen Versions-Tag herunterladen und bei sich integrieren.

Sobald dann ein offizielles Helm-Chart für den Keycloak-Operator zur Verfügung steht, wird dieses Vorgehen mit einem Update der Helm-Chart-Version um einiges komfortabler und Entwickler können es mit dem populären Tool renovate einfacher managen.

Unser Open-Source-Projekt kubriX wird auf jeden Fall nach der Umstellung am 28. August keine Bitnami-Images oder Helm-Charts mehr benötigen.

Eins ist mir noch wichtig festzuhalten: Es steht jeder Firma natürlich frei, ihr Geschäftsmodell rund um ihre Open-Source-Projekte so zu wählen, wie es ihr gefällt. Und jedem muss klar sein, dass Firmen auch im Open-Source-Umfeld Geld verdienen müssen. Sonst überlebt das beste Projekt nicht. Allerdings sind die kolportierten Preismodelle von Broadcom wohl nicht darauf ausgelegt, die breite Masse anzusprechen, obwohl sehr viele Contributoren in der Vergangenheit zur Qualität der Bitnami-Charts und -Images beigetragen haben.

Dementsprechend bin ich gespannt, wo sich das Bitnami-Projekt hinbewegt. Wir unterstützen auf jeden Fall weiterhin diverse Open-Source-Projekte und -Organisationen, von Bitnami müssen wir uns allerdings verabschieden.

Johannes, vielen Dank für das Gespräch!


(who)



Source link

Weiterlesen

Entwicklung & Code

software-architektur.tv: KI-Architektur zwischen Hype und Realität


Diese Folge des Videocasts dreht sich um das Eichhörnchen im Kopf – die KI-Architektur zwischen Hype und Realität. Kimi 2, Grok 4, Windsurf, Metas Manhattan-große KI-Rechenzentren – jeden Tag neue KI-Tools, Ankündigungen und Versprechen. Das Eichhörnchen im Kopf springt im Sekundentakt zwischen den Themen hin und her. Wie sollen Softwarearchitektinnen und -architekten da noch den Überblick behalten und fundierte Entscheidungen treffen?

Barbara Lampl kennt dieses Problem aus erster Hand: Als KI-Expertin beobachtet sie täglich die rasante Entwicklung der KI-Landschaft und weiß, wie überwältigend die Informationsflut sein kann. In dieser Folge diskutieren Ralf D. Müller und Barbara Lampl, wie man als Architekt einen klaren Kopf behält, wenn das Eichhörnchen mal wieder Vollgas gibt.

Eine Folge für alle, die sich manchmal fragen: „Passt das alles eigentlich noch zusammen?“ – Spoiler: Ja, aber es ist komplexer, als vielen lieb ist.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 15. August

Die Ausstrahlung findet live am Freitag, 15. August 2025, 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.


(mai)



Source link

Weiterlesen

Beliebt