Connect with us

Entwicklung & Code

Halbierte Latenz: Webframework IHP 1.5.0 mit neuer Datenbankschicht


Das Webframework IHP liegt in Version 1.5.0 vor. Es handelt sich um das bisher größte Release des Open-Source-Projekts mit 1.051 Commits. Die Entwickler haben die gesamte Datenbankschicht neu geschrieben, die Performance an vielen Stellen verbessert und die Architektur modularisiert.

Weiterlesen nach der Anzeige

IHP (Integrated Haskell Platform) ist ein Webframework, das viele für Webanwendungen typische Funktionen bereits ab Werk mitbringt. Es kombiniert die funktionale Programmiersprache Haskell mit dem Paketmanager Nix. Nix sorgt dabei für reproduzierbare Entwicklungsumgebungen. Das Framework richtet sich an Entwickler und Teams, die Webanwendungen mit hoher Typsicherheit und möglichst wenigen Laufzeitfehlern bauen wollen. IHP liefert dafür alle nötigen Werkzeuge mit – vom Prototyping bis zur Produktion.

Die größte Änderung in Version 1.5.0 betrifft den Datenbankzugriff. IHP wechselt vom älteren Treiber postgresql-simple auf hasql. Dieser aktuellere Treiber nutzt das binäre Protokoll von PostgreSQL und arbeitet mit vorbereiteten Anweisungen (Prepared Statements). In Produktionsumgebungen sinkt die Latenz bei Datenbankabfragen dadurch um bis zu 50 Prozent. Die bestehende Query-Builder-API bleibt unverändert – vorhandener Code funktioniert ohne Anpassungen weiter. Nur wer bisher direkt auf postgresql-simple zugegriffen hat, muss migrieren.

Darüber hinaus haben die IHP-Entwickler auch andere Teile des Frameworks beschleunigt. Laut Release Notes belegt der integrierte Entwicklungsserver – er basiert auf GHCi, der interaktiven Umgebung des Haskell-Compilers – jetzt nur noch 500 bis 800 MByte Arbeitsspeicher statt zuvor 4 GByte. Ferner soll die Session-Middleware bei Routen, die nicht auf die Session zugreifen, dreimal schneller arbeiten. Die URL-Generierung soll nach dem Update fünfmal schneller und die Render-Pipeline doppelt so schnell wie in der Vorgängerversion sein.

Das neue Paket ihp-typed-sql führt einen sogenannten Quasiquoter ein – ein Haskell-Mechanismus, der SQL-Syntax direkt im Code erlaubt. Das Besondere: Der Compiler verbindet sich während des Übersetzungsvorgangs mit der Entwicklungsdatenbank und prüft, ob Tabellen, Spalten und Datentypen korrekt sind. Er erkennt auch, welche Spalten durch LEFT JOIN Null-Werte annehmen können. Fehlerhafte SQL-Abfragen fallen so bereits beim Build auf, nicht erst zur Laufzeit.

Mit der neuen Funktion fetchPipelined können Entwickler mehrere unabhängige Datenbankabfragen in einem einzigen Netzwerk-Roundtrip an PostgreSQL senden. Statt jede Abfrage einzeln abzuschicken und auf die Antwort zu warten, schickt IHP alle Abfragen direkt hintereinander. Die Datenbank verarbeitet sie und liefert die Ergebnisse gebündelt zurück. Das reduziert die Netzwerklatenz spürbar.

Weiterlesen nach der Anzeige

IHP ist mit dieser Version weniger monolithisch aufgebaut. Die Entwickler haben über 15 Module – darunter ihp-mail, ihp-datasync und ihp-schema-compiler – als eigenständige Pakete auf Hackage veröffentlicht, dem zentralen Paket-Repository für Haskell (vergleichbar mit npm für JavaScript oder PyPI für Python). Andere Haskell-Projekte können diese Bibliotheken damit nutzen, ohne das gesamte Framework einzubinden. Bestehende IHP-Projekte sind nicht betroffen: Die Module werden weiterhin aus dem Hauptpaket re-exportiert.

Darüber hinaus bringt Version 1.5.0 unter anderem Custom Routes für individuelle URLs neben dem automatischen Routing, Unterstützung für zusammengesetzte Primärschlüssel (Composite Primary Keys) und einen Integrationstestmodus mit automatisch erzeugter temporärer PostgreSQL-Datenbank. Als Standard-Compiler dient nun GHC 9.10, experimentell unterstützt IHP auch GHC 9.12.

Da der Wechsel der Datenbankschicht und die Modularisierung einige inkompatible Änderungen (Breaking Changes) mit sich bringen, stellt das Entwicklerteam einen Upgrade-Guide mit Schritt-für-Schritt-Anleitung bereit. Alle Informationen finden sich in den Release Notes auf GitHub.


(fo)



Source link

Entwicklung & Code

software-architektur.tv: Wie unabhängig ist dein Service wirklich?


Der fachliche Schnitt eines Systems entscheidet darüber, ob es langfristig änderbar bleibt. Doch wie findet man einen sinnvollen Schnitt, ohne sich direkt in die Komplexität von Domain-Driven Design zu stürzen?

Weiterlesen nach der Anzeige

In dieser Episode von software-architektur.tv wirft Eberhard Wolff einen Blick auf die Independent Service Heuristics (ISH) aus dem Team-Topologies-Umfeld. Sie liefern einfache, aber wirkungsvolle Fragen, um zu beurteilen, ob ein „Ding“ als eigenständiger Service funktionieren kann.

Eberhard Wolff erörtert, wie diese Heuristiken helfen, Domänengrenzen greifbarer zu machen, warum sie besonders gut mit Business-Expertinnen und -Experten funktionieren und wo ihre Grenzen liegen. Am Ende steht ein pragmatischer Ansatz für alle, die bessere Services schneiden wollen – ohne sich in Abstraktionen zu verlieren.

Die Ausstrahlung findet am Freitag, 27. März 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.

Weiterlesen nach der Anzeige


(map)



Source link

Weiterlesen

Entwicklung & Code

KubeCon EU 2026: Kubernetes wird weiter als Infrastruktur für KI optimiert


Auf der KubeCon und CloudNativeCon Europe 2026 in Amsterdam spielte Infrastruktur für KI wie auch letztes Jahr eine zentrale Rolle. Ein Großteil von Trainings- und Inferenz-Workloads laufen auf Beschleunigern von Nvidia. Jetzt stellt das Unternehmen den Dynamic-Resource-Allocation-Treiber (DRA) für seine GPUs unter die Schirmherrschaft der CNCF (Cloud Native Computing Foundation). Mit dem Treiber kann Kubernetes flexibel GPU-Ressourcen anfragen und umverteilen, mittels NVLink über eine Vielzahl von Kubernetes-Nodes, auf denen DRA aktiviert ist.

Weiterlesen nach der Anzeige

Flankiert wird der DRA-Treiber von einem neuen Open-Source-Werkzeug namens AI Cluster Runtime (AICR), das reproduzierbar GPU-beschleunigte Kubernetes-Cluster hochzieht. Es erstellt Snapshots und schreibt die Kombination aus Treiber, Kubernetes-Operator, Kernel und Systemkonfiguration in sogenannte Rezepte, die später von einem Paketmanager wie Helm oder einem GitOps-Werkzeug wie Argo CD genutzt und gegen die AI-Conformance-Anforderungen der CNCF validieren.

Das AI-Conformance-Programm der CNCF baut auf dem Kubernetes-Conformance-Programm auf. Die Zahl der Plattformen, die sich „certified AI Platform“ nennen dürfen, hat sich seit dem Start im November von 18 auf 31 nahezu verdoppelt. Neu dazu gekommen sind unter anderem OVHcloud, SpectroCloud, JD Cloud und China Unicom Cloud.

Eines der neuen CNCF-Projekte ist llm-d, das im Mai 2025 von Red Hat, Google Cloud, IBM, CoreWeave und Nvidia ins Leben gerufen wurde. Bisherige Methoden in Kubernetes für Routing, Autoscaling und Cache sind nicht unbedingt für Inferenz geeignet, weil es sich um einen höchst variablen und gleichzeitig Zustands-behafteten Workload handelt.



(Bild: CNCF)

Das Projekt orchestriert Kubernetes-Cluster und nutzt die Inferenz-Erweiterung für das Kubernetes Gateway API (GAIE). Die Verarbeitung von Prompts und Token-Generierung wird auf verschiedene Pods aufgeteilt, die unabhängig voneinander skaliert werden können. Außerdem verwaltet es den State und kümmert sich um Prefix-Caching. Dabei ist llm-d komplett Hardware-agnostisch und arbeitet mit CPUs, GPUs und TPUs verschiedener Hersteller. Inferenz-Optimierung mit llm-d soll die Time to First Token (TTFT) deutlich verringern und den Token-Durchsatz steigern.

Weiterlesen nach der Anzeige

CNCF-Projekte werden je nach Reifegrad den Kategorien Sandbox, Incubating und Graduation zugeordnet. Die Policy Engine Kyverno hat den höchsten Reifegrad erreicht und ist jetzt ein graduiertes Projekt.

Neben llm-d ist auch das Agones-Projekt ein Neuzugang in der Sandbox-Kategorie. Die Plattform zur Orchestrierung von Gameservern wurde 2017 von Ubisoft und Google ins Leben gerufen und jetzt an die CNCF übergeben.

Man hätte meinen können, dass das CNCF-Event in Europa Open Source als Schlüssel zu Digitaler Souveränität mehr in den Fokus rückt. Man betonte jedoch lediglich, dass Code global verfügbar ist und weiter verfügbar bleiben muss. Gesetzesvorgaben und Compliance-Vorschriften seien auf Deployment- und Plattformebene zu lösen. Das Thema Souveränität wurde größtenteils in den Open Sovereign Cloud Day ausgelagert.

c’t Open Source Spotlight abonnieren

Innovative Software, spannende Projekte: Erweitern Sie Ihre Möglichkeiten und werden Sie Teil der Open Source Community.

E-Mail-Adresse

Ausführliche Informationen zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten erhalten Sie in unserer Datenschutzerklärung.

Mit etwa 13.000 Teilnehmenden aus 100 Ländern und einem umfangreichen Programm aus 900 Sessions war die Konferenz bislang die größte KubeCon und CloudNativeCon.


(ndi)



Source link

Weiterlesen

Entwicklung & Code

KubeCon EU 2026: Solo.io bringt Observability für KI-Agenten-Workflows


Solo.io hat im Rahmen der KubeCon EU 2026 mit agentevals ein Open-Source-Werkzeug vorgestellt, das die Qualität von KI-Agenten messbar machen soll. Aus dem Bereich der LLMs (Large Language Models) kennt man den Vergleich von Eingabe und Ausgabe. Doch dieser Ansatz genügt bei Agenten nicht, denn sie greifen auf weitere Werkzeuge, Informationssysteme oder sogar andere KI-Komponenten zurück. Wie gut und effektiv ist die Schleife von Aufrufen? Das umfasst die Daten, die hin- und herfließen, aber auch die Auswahl der externen Instanzen und deren Anzahl.

Weiterlesen nach der Anzeige


Logo der Konferenz Mastering Observabilkity 2026

Logo der Konferenz Mastering Observabilkity 2026

(Bild: AtemisDiana/Shutterstock)

Mehr zu Observability bietet die Online-Konferenz Mastering Observability von iX und dpunkt.verlag am 16. April 2026. Die Konferenz widmet sich unter anderem den Herausforderungen automatisierter Observability für KI- und agentenbasierte Systeme.

Für diese Auswertung macht sich agentevals bereits bekannte Methoden aus dem Machine Learning zunutze und verwendet vorhandene Telemetriedaten. Außerdem können Anwender eigene Metriken definieren und Schwellenwerte festlegen. Letzteres bezeichnet das Projekt als „Golden Eval Sets“.


Beispielhafte Auswertung von agentevals mit einer Liste von Evaluators

Beispielhafte Auswertung von agentevals mit einer Liste von Evaluators

Beispielhafte Auswertung von agentevals mit einer Liste von Evaluators

Damit lassen sich Agenten evaluieren, bevor sie in Produktion gehen. Tut die Software, was sie soll? Arbeitet sie kosteneffizient und mit den richtigen Mitteln? Agentenbasierte KI arbeitet konstruktionsbedingt nicht deterministisch – gleiche Eingaben können also unterschiedliche Ergebnisse liefern. Agentevals soll einen Teil dieser Vorhersagbarkeit wiederherstellen. Am einfachsten gelingt die Integration über OpenTelemetry, ein offenes Observability-Framework für verteilte Systeme. Hier lassen sich entsprechende Agenten ohne Codeänderung anweisen, ihre Telemetriedaten an die agentevals-Plattform zu schicken. Ebenso lassen sich historische Daten auswerten. Ein bereits entsprechend dokumentierter Agentenlauf lässt sich im Nachhinein mit agentevals inspizieren. Dafür bietet das Werkzeug eine webbasierte Oberfläche und einen Kommandozeilenzugang.

Zusammen mit agentevals hat Solo.io bereits vier Projekte im Bereich der KI-Agent-Infrastruktur veröffentlicht. Im Gespräch mit heise erklärte Keith Babo, Vice President, Product bei Solo.io, dass jedes Mal dieselbe Motivation dahinterstand. Die Frage lautete jeweils: Welche Lücke im Ökosystem der KI-Agenten muss dringend geschlossen werden? Den Anfang machte kagent. Das Framework ermöglicht es, KI-Agenten nativ in Kubernetes – der weitverbreiteten Container-Orchestrierungsplattform – zu betreiben. Danach folgte agentgateway, eine Data Plane – also die Komponente, die den eigentlichen Datenverkehr verarbeitet – für KI-Agenten beziehungsweise deren Plattform. Sie unterstützt unter anderem die Protokolle MCP (Model Context Protocol) und A2A (Agent-to-Agent). Mit agentregistry lassen sich KI-Artefakte zentral verwalten und auditieren.

Weiterlesen nach der Anzeige

Auf der KubeCon EU 2026 in Amsterdam übergab Solo.io agentregistry an die CNCF (Cloud Native Computing Foundation) und findet dort mit kagent sogar schon einen Bekannten; agentgateway liegt bei der Linux Foundation. Offen ist, welcher Foundation agentevals zugeordnet wird – und welche Lücke Solo.io als Nächstes schließen will.

Keith Sabo vermutet, dass im nächsten Schritt MCP und dessen breiterer Einsatz in den Fokus rücken. Konkret: Wie lassen sich bestehende REST-APIs in die Welt von KI und Model Context Protocol überführen? Eine 1:1-Abbildung funktioniert dabei nicht. Alles von Grund auf neu zu entwickeln, ist aber oft ebenfalls keine Option. Es bleibt abzuwarten, ob Solo.io dieses Thema als Nächstes angeht.


(map)



Source link

Weiterlesen

Beliebt