Connect with us

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

Entwicklung & Code

DeepSeek senkt API-Preise um 50 Prozent und stellt V3.2-Exp vor


Das chinesische KI-Start-up DeepSeek hat mit V3.2-Exp eine experimentelle Version seines Sprachmodells veröffentlicht und gleichzeitig die Preise für seine API-Dienste um mehr als 50 Prozent gesenkt. Wie das Unternehmen auf seiner Hugging-Face-Seite mitteilte, markiert die neue Version einen Zwischenschritt zur nächsten Generation der KI-Architektur.

Das erst im Jahr 2023 gegründete Unternehmen, das Anfang des Jahres mit seinem R1-Modell für Aufsehen im Silicon Valley gesorgt hatte, arbeitet nach eigenen Angaben mit chinesischen Chipherstellern an der Weiterentwicklung seiner Modelle. Die neue Version V3.2-Exp baut auf dem älteren V3.1-Modell auf und führt eine neue Technik namens DeepSeek Sparse Attention (DSA) ein.

Die Sparse-Attention-Technologie soll die Effizienz bei der Verarbeitung langer Textsequenzen verbessern. Während herkömmliche Attention-Mechanismen bei großen Sprachmodellen alle Tokens gleichzeitig berücksichtigen, konzentriert sich DSA nur auf die relevantesten Bereiche des Inputs. Dies reduziert den Rechenaufwand laut DeepSeek erheblich, ohne die Qualität der Ausgabe wesentlich zu beeinträchtigen.

Parallel zur Modellveröffentlichung kündigte DeepSeek eine drastische Preissenkung für seine API-Dienste um mehr als 50 Prozent an. Die neuen Tarife gelten sofort und sollen dem Unternehmen helfen, mehr Nutzer zu gewinnen. Zum Vergleich bleibt das bisherige V3.1-Terminus-Modell bis zum 15. Oktober 2025 über eine temporäre API verfügbar.

Huawei, der führende Anbieter von KI-Chips in China, kündigte an, dass seine Produkte das neueste DeepSeek-Modell unterstützen werden.

DeepSeek hat außerdem angegeben, dass die neuesten Versionen seiner Modelle mit simplen 8-Bit-Gleitkommawerten (Floating Point 8, FP8) umgehen kann, während an der Implementierung von BF16 (Brain Floating Point 16) gearbeitet wird. FP8 ermöglicht theoretisch Speichereinsparungen und schnellere Berechnungen, da es weniger Speicherplatz benötigt und die Matrizen vergleichsweise simpel sind. Obwohl FP8 weniger präzise ist als klassische Formate wie FP32, gilt es für KI-Anwendungen als ausreichend genau.

BF16 hingegen stellt einen Kompromiss zwischen Geschwindigkeit und Präzision dar. Die Unterstützung beider Formate soll es ermöglichen, große Modelle auch auf Hardware mit begrenzten Ressourcen zu betreiben.

Mit der Preissenkung um mehr als 50 Prozent positioniert sich DeepSeek aggressiv im umkämpften KI-API-Markt. Das Unternehmen reiht sich damit in eine Reihe chinesischer Start-ups ein, die durch niedrige Preise Marktanteile gewinnen wollen. Input-Token kosten bei DeepSeek künftig 0,28 US-Dollar pro Million Token statt bislang 0,56 US-Dollar. Mit Cache sinkt der Preis sogar auf 0,028 US-Dollar. Eine Million Output-Token kosten 0,42 US-Dollar. Vorbehalte gegenüber chinesischen Modellen gibt es beim Datenschutz und der staatlichen Zensur Chinas.


(mki)



Source link

Weiterlesen

Entwicklung & Code

PHP 8.5 setzt auf Lesbarkeit, Debugging-Features und mehr Sicherheit


Am 20. November 2025 soll PHP 8.5 offiziell erscheinen – jetzt liegt der erste Release Candidate vor. Die kommende Version konzentriert sich auf Verbesserungen bei der Lesbarkeit von Code, neuen Utility-Funktionen, erweiterten Debugging-Möglichkeiten sowie Detailverbesserungen in der Performance und Sicherheit.

PHP 8.5 führt den neuen Pipe-Operator |> ein. Entwicklerinnen und Entwickler können damit Funktionsaufrufe linear verketten, anstatt verschachtelte Strukturen zu schreiben. Das Beispiel aus dem RFC soll dies verdeutlichen:


function getUsers(): array {
    return [
        new User('root', isAdmin: true),
        new User('john.doe', isAdmin: false),
    ];
}
 
function isAdmin(User $user): bool {
    return $user->isAdmin;
}
 
// This is the new syntax.
$numberOfAdmins = getUsers()
    |> (fn ($list) => array_filter($list, isAdmin(...))) 
    |> count(...);
 
var_dump($numberOfAdmins); // int(1);


Mit array_first() und array_last() holen Developer den ersten oder letzten Wert eines Arrays, ohne den Array-Pointer zu verändern (siehe RFC):


function array_first(array $array): mixed {}
function array_last(array $array): mixed {}


Die neuen Funktionen get_error_handler() und get_exception_handler() geben direkten Einblick in die aktiven Handler. PHP liefert außerdem bei fatalen Fehlern nun vollständige Stack-Traces und blendet sensible Parameter automatisch aus, wenn sie mit #[\SensitiveParameter] markiert sind.

PHP 8.5 erlaubt es, im Rahmen der Constructor Property Promotion direkt Final Properties zu deklarieren (siehe RFC). Entwickler sparen damit Boilerplate-Code und definieren finale Properties genauso wie normale Properties im Constructor.

Das Attribut #[\NoDiscard] warnt, wenn wichtige Rückgabewerte ungenutzt bleiben. Zudem unterstützt PHP jetzt statische Closures in Konstanten, Default-Parametern und Attributen.

Die Funktion locale_is_right_to_left() erkennt Sprachen, die von rechts nach links gelesen werden. curl_multi_get_handles() vereinfacht das Management von cURL-Multi-Handles. Mit der Konstante PHP_BUILD_DATE und dem CLI-Befehl php --ini=diff will das Entwicklerteam hinter der Programmiersprache Debugging und Auditing vereinfachen.

iX sprach mit Volker Dusch, Release Manager zu PHP 8.5, der bestätigte: „Die Timeline ist eingehalten, alle Feature-RFCs sind eingebaut und wie immer gut getestet.“ Bei einer von 46 Deprecations habe es Anpassungsbedarf für das PHP-Framework Symfony gegeben, wofür ein Follow-up-RFC erstellt worden sei – ein normaler Vorgang. Substanzielle Änderungen habe es seit den Betas nicht mehr gegeben. „Es gibt keine signifikanten Breaking Changes. Deprecations sind lediglich Hinweise auf künftige Anpassungen,“ so Dusch.


betterCode() PHP am 25. November 2025

betterCode() PHP am 25. November 2025

(Bild: nuevoimg / 123rf.com)

Am 25. November findet die betterCode() PHP statt, eine Online-Konferenz von iX und dpunkt.verlag in Kooperation mit thePHP.cc. Interessierte können sich in Vorträgen und Diskussionsrunden über die Programmiersprache informieren. Vergünstigte Tickets zum Early-Bird-Tarif sind über die Konferenz-Website erhältlich.

PHP 8.5 bringt keine Revolution, aber viele durchdachte Verbesserungen. Von schlankerem Code mit dem Pipe-Operator, über sicherere Fehlerbehandlung bis hin zu neuen Debugging-Werkzeugen richtet sich der Fokus klar auf die Developer Experience. Weitere Informationen zum Release finden sich auf GitHub oder auf php.net.


(mdo)



Source link

Weiterlesen

Entwicklung & Code

Postgres 18: Dreimal schnellere asynchrone Abfragen und virtuelle Spalten


Die neue Version von Postgres 18 bringt eine Reihe von Verbesserungen der Performance und neue Funktionen wie den Zugriff auf alte Werte bei INSERT oder virtuelle Spalten für Abfragen. Für die sichere Authentifizierung bietet die Datenbank OAuth 2 und für das Passwort-Hashing wird SHA-256 verpflichtend.

Die wichtigste Neuerung für beschleunigte Abfragen ist das asynchrone IO-Subsystem (AIO), das „bis zu dreifache Performance-Verbesserungen beim Lesen aus dem Speicher bewiesen hat“, heißt es in der Ankündigung. AIO beschleunigt Read-ahead-Prozesse, für die die Datenbank entsprechende Mechanismen des jeweiligen Betriebssystems nutzt. Diese Mechanismen kennen nicht alle Spezifika einer Datenbank und können oft nicht richtig vorhersagen, welche Daten demnächst benötigt werden. AIO stellt nun mehrere parallele asynchrone Anfragen und beschleunigt so Read-ahead-Abfragen. AIO-Operationen umfassen sequenzielle und Bitmap-Heap-Scans sowie den VACUUM-Befehl.

Anwenderinnen und Anwender können in den Einstellungen für io_method zwischen AIO und dem alten synchronen System umschalten. Weitere Geschwindigkeitsgewinne ergeben sich durch Skip-Scan-Suchen bei mehrspaltigen B-tree-Indizes sowie durch eine verbesserte Ausführung von table joins und hash joins. Hardware-Beschleunigung gibt es nun für ARM NEON und SVE CPU.

Lesen Sie auch

Die automatischen Statistiken gehen ab Postgres 18 auch bei großen Updates nicht verloren, sodass die durch die Statistik aufgebauten Systemerkenntnisse erhalten bleiben. Das garantiert verbesserte Leistungswerte über ein Update hinaus.

Entwicklerinnen und Entwickler legen mit Postgres 18 nun virtuelle Spalten an, die Abfragen verarbeiten, ohne dass die Datenbank diese speichert. Das ist künftig die Standardoption. Auch gespeichert erzeugte Tabellen können Anwender künftig logisch replizieren.

Erfreuen wird viele Developer, dass sie bei den Befehlen INSERT, UPDATE, DELETE und MERGE nun auch Zugriff auf alte (OLD) Werte haben und nicht nur und neuen (NEW). Außerdem können sie zufällige UUIDs mit uuidv7() einsetzen, die sich über Zeitstempel sortieren und besseres Caching erlauben.

Ferner lassen sich entfernte Tabellen auf der Basis von lokalen Schemata einfach mit dem Befehl CREATE FOREIGN TABLE ... LIKE erzeugen.

Für die Authentifizierung von Anwendern unterstützt Postgres 18 OAuth 2. Weitere Sicherheitsfunktionen sind eine SSL-Validierung mit FIPS und ein Parameter ssl_tls13_ciphers für TLS 1.3. Außerdem ist MD 5 für das Passwort-Hashing veraltet und wird demnächst deaktiviert. Postgres erfordert jetzt SCRAM-SHA-256

Details und weitere Neuerungen finden sich in der Ankündigung und den Release Notes.


(who)



Source link

Weiterlesen

Beliebt