Connect with us

Entwicklung & Code

Won’t fix! – Teil 2: Warum sich Bugs nicht systematisch eliminieren lassen


Wie lange braucht man, um ein fehlerfreies Programm zu schreiben? Wenn das Programm nur eine einzige Zeile umfasst, sollte die Antwort lauten: gar nicht lange. „Hello World“ ist das erste Programm, das die meisten Entwicklerinnen und Entwickler in einer neuen Sprache schreiben. Es macht genau eine Sache: einen Text auf dem Bildschirm ausgeben. Fehler sind in einem solchen Programm kaum vorstellbar.

Weiterlesen nach der Anzeige


Golo Roden

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.

Die Serie „Wont‘ fix“ behandelt Probleme in der Softwareentwicklung, die sich nicht wegoptimieren lassen, mit denen man aber lernen kann umzugehen:

Und doch weist „Hello World“ in den meisten Programmiersprachen einen Bug auf. Der Entwickler Dan Gohman hat das 2022 in einem viel beachteten Blogbeitrag anhand des folgenden Codes demonstriert:


#include 
#include 
int main(void)
{
  puts("Hello World!");
  return EXIT_SUCCESS;
}


Linux bietet mit /dev/full eine Gerätedatei an, die sich wie eine volle Festplatte verhält. Leitet man die Ausgabe eines Hello-World-Programms dorthin um, schlägt der Schreibvorgang fehl, das Betriebssystem meldet „No space left on device“. Das Programm aber meldet Erfolg. In C, C++, Java, Ruby, Python 2, Node.js und Haskell verschluckt „Hello World“ den Fehler stillschweigend und gibt den Exit-Code 0 zurück, als wäre nichts geschehen. Andere Sprachen machen es besser: Python 3, Rust, Perl, Bash, OCaml, Tcl, C# und – durchaus bemerkenswert – Awk erkennen den Fehler korrekt und melden ihn. Dass ausgerechnet eine Skriptsprache aus den 1970er-Jahren gewissenhafter mit Fehlern umgeht als moderne Mainstream-Sprachen, ist eine der Pointen dieses Experiments.

Die Annahme, dass die Standardausgabe immer funktioniert, ist so tief eingebrannt, dass sie niemand hinterfragt. Dabei ist das Szenario keineswegs akademisch: Jedes Programm, das seine Ausgabe in eine Datei umleitet, kann auf eine volle Festplatte treffen. Wenn es den Fehler nicht erkennt und meldet, arbeitet der aufrufende Prozess stillschweigend mit unvollständigen Daten weiter. Wenn schon das einfachste denkbare Programm nicht fehlerfrei ist, was bedeutet das für echte Software?


Aufmacher betterCode() Testing

Aufmacher betterCode() Testing

(Bild: laolina/123rf.com)

Die betterCode() Testing 2026 zeigt am 8. Juni 2026, wie das Zusammenspiel von Mensch, Tools und Prozessen den Erfolg moderner Software sichert. Im Fokus stehen Testing mit und von KI, Testautomatisierung und Praxisberichte, die zeigen, was wirklich getestet werden sollte.

Testen heißt nicht beweisen

Weiterlesen nach der Anzeige

In der professionellen Softwareentwicklung fehlt es nicht an Maßnahmen gegen Fehler. Unit-Tests, Integrationstests, statische Codeanalyse, Reviews, automatisierte CI/CD-Pipelines: Die Werkzeuge sind vielfältig und ausgereift, und die entsprechenden Prozesse oftmals schon seit vielen Jahren etabliert. Und trotzdem landen regelmäßig Bugs in produktiv laufendem Code. Das liegt in der Natur des Testens selbst.

Edsger Dijkstra brachte es bereits in den 1970er-Jahren auf den Punkt: Testen kann die Anwesenheit von Fehlern zeigen, niemals aber ihre Abwesenheit. Denn bei Tests handelt es sich lediglich um Stichproben. Sie prüfen ausgewählte, aber niemals alle denkbaren Fälle. Ein Test, der hundert Eingaben korrekt verarbeitet, sagt nichts über die hundertunderste. Selbst eine Testabdeckung von hundert Prozent, gemessen an den Codezeilen, bedeutet lediglich, dass jede Zeile mindestens einmal ausgeführt wurde. Sie sagt nichts darüber aus, ob alle relevanten Kombinationen von Eingaben, Zuständen und Umgebungsbedingungen abgedeckt sind. Bei einem Programm mit zwanzig booleschen Parametern gibt es bereits über eine Million mögliche Kombinationen. Kein Test der Welt deckt das vollständig ab.

Die meisten Entwicklerinnen und Entwickler kennen den Effekt aus eigener Erfahrung: Sie haben sich Mühe gegeben, sorgfältig getestet, alle bekannten Szenarien abgedeckt. Dann nutzt die Kundin oder der Kunde die Software zum ersten Mal, und innerhalb von Minuten ist ein Fehler aufgetreten, den niemand vorhergesehen hat. Das liegt nicht daran, dass das Team schlecht getestet hätte. Es liegt daran, dass Kundinnen und Kunden andere Annahmen mitbringen, andere Reihenfolgen ausprobieren, andere Eingaben machen und auf anderem Wege zu den gleichen Funktionen gelangen. Sie testen nicht systematisch, sondern benutzen die Software. Und genau das deckt Fehlerklassen auf, die in keinem Testplan stehen.

Ein Beispiel aus der Praxis illustriert das auf lehrreiche Weise. Mein Unternehmen entwickelt eine Datenbank, deren API und UI über HTTP erreichbar sind. Selbstverständlich wurde alles vor der Veröffentlichung der ersten Version ausgiebig getestet, einschließlich der Konfiguration verschiedener Netzwerk-Ports. Der Standardport 3000, übliche Alternativen wie 8080 und 5000, diverse hohe Portnummern: Alles funktionierte einwandfrei. API-Aufrufe über curl und Postman, Integrationstests, manuelle Tests – es gab keinerlei Auffälligkeiten.

Nur wenige Stunden nach der Veröffentlichung trudelte der erste Bugreport ein: „Die UI lädt nicht auf Port 6000“. Also suchte das Team im gesamten Code nach dem Fehler. Das Routing im Webserver war korrekt. Die CORS-Header waren korrekt. Alles sah richtig aus. Erst die Netzwerkanalyse im Browser brachte die Lösung: Die Anfragen verließen den Browser erst gar nicht. Sie wurden blockiert, bevor sie das Netzwerk erreichten.

Alle Browser der Chrome-Familie blockieren nämlich die Ports 6000 bis 6063 aus Sicherheitsgründen, weil dort traditionell das X-Window-System (X11) lauscht, dessen Netzwerkprotokoll historisch anfällig für Angriffe war. Diese Entscheidung wurde vor Jahren getroffen, vergraben im Quellcode der Browser und in Spezifikationen. Aus Sicht des Betriebssystems gibt es keinen Unterschied zwischen Port 5999 und Port 6000. Aus Sicht des Browsers schon. Kein Test hatte diesen Fall abgedeckt, weil niemand Anlass hatte, danach zu suchen. Es war, wie der Hello-World-Bug, ein Fehler in der Lücke zwischen dem eigenen System und den Annahmen über die Umgebung.

Solche Fehler haben ein gemeinsames Muster: Sie entstehen dort, wo niemand hinschaut, weil es vermeintlich keinen Grund gibt, dorthin zu schauen. Und genau deshalb lassen sie sich durch Tests nicht zuverlässig finden, denn Tests prüfen stets nur das, woran jemand zuvor gedacht hat.

Die Frage liegt nahe, ob es nicht ein Werkzeug geben könnte, das ein Programm vollständig analysiert und zuverlässig feststellt, ob es fehlerfrei ist. Nicht durch Stichproben wie Tests, sondern durch systematische Prüfung aller möglichen Ausführungspfade. Ein perfekter Bug-Detektor, der jedes Programm entgegennimmt und mit Sicherheit feststellt, ob das Programm fehlerfrei ist oder nicht. Die Vorstellung ist verlockend. Jede Softwarefirma würde ein solches Werkzeug sofort kaufen, und es würde die Branche grundlegend verändern.

Der britische Mathematiker Alan Turing bewies 1936, dass ein solches Werkzeug nicht existieren kann. Er zeigte das nicht einmal anhand der Frage nach Bugs, sondern anhand einer viel einfacheren Frage: Lässt sich für ein beliebiges Programm und eine beliebige Eingabe entscheiden, ob das Programm irgendwann anhält oder endlos weiter läuft? Diese Frage ist als das Halteproblem bekannt, und Turings Beweis, dass sie nicht allgemein beantwortbar ist, gehört zu den folgenreichsten Erkenntnissen der theoretischen Informatik.

Die Beweisidee lässt sich ohne Formalismen leicht skizzieren. Angenommen, es gäbe ein Analyseprogramm H, das für jedes Programm P und jede Eingabe E korrekt vorhersagt, ob P bei Eingabe E anhält. Dann ließe sich ein neues Programm D konstruieren, das H als Baustein verwendet und wie folgt arbeitet: D nimmt ein Programm P als Eingabe, fragt H, ob P bei Eingabe P anhält, und tut dann das Gegenteil. Wenn H vorhersagt, dass P anhält, läuft D endlos weiter. Wenn H vorhersagt, dass P endlos läuft, hält D an.

Was würde nun passieren, wenn D sich selbst als Eingabe erhielte? Wenn H vorhersagt, dass D anhält, dann läuft D endlos weiter, also lag H falsch. Wenn H hingegen vorhersagt, dass D endlos läuft, dann hält D an, also lag H wieder falsch. In beiden Fällen irrt sich H. Das Analyseprogramm H kann also nicht existieren, weil seine Existenz zu einem logischen Widerspruch führt.

Das Halteproblem mag abstrakt klingen, aber seine praktische Bedeutung ist weitreichend. Jede Entwicklerin und jeder Entwickler ist ihm bereits begegnet, ohne es vielleicht so zu nennen: eine Endlosschleife, die nur unter bestimmten Bedingungen auftritt. Ein rekursiver Aufruf, der in einem Sonderfall nicht terminiert. Ein Deadlock, der sich erst unter Last manifestiert. All das sind Instanzen des Halteproblems. Die Frage „Wird mein Programm in diesem Fall jemals fertig?“ ist nicht generell beantwortbar. Und wenn es nicht einmal möglich ist, zuverlässig festzustellen, ob ein Programm jemals zu einem Ergebnis kommt, dann ist es erst recht nicht möglich, zuverlässig festzustellen, ob es das richtige Ergebnis liefert.

Was sich nicht entscheiden lässt

Das Halteproblem ist kein Einzelfall. Der Mathematiker Henry Gordon Rice bewies 1953 ein Theorem, das die Tragweite von Turings Ergebnis drastisch erweitert: Jede nicht-triviale Eigenschaft des Verhaltens eines Programms ist unentscheidbar. Nicht-trivial bedeutet hier, dass es mindestens ein Programm gibt, das die Eigenschaft besitzt, und mindestens eines, das sie nicht besitzt.

Die praktischen Konsequenzen sind erheblich. „Behandelt dieses Programm alle Fehlerfälle korrekt?“ ist eine nicht triviale Eigenschaft, also unentscheidbar. „Greift dieses Programm jemals auf unerlaubten Speicher zu?“ ist unentscheidbar. „Gibt dieses Programm für alle gültigen Eingaben die spezifizierte Ausgabe zurück?“ ist unentscheidbar. „Sendet dieses Programm jemals Daten an eine nicht autorisierte Adresse?“ ist unentscheidbar. Für keine dieser Fragen kann ein allgemeines Analysewerkzeug existieren, das für jedes beliebige Programm die korrekte Antwort liefert.

Das Theorem von Rice erklärt, warum die Suche nach dem einen Werkzeug, das alle Bugs findet, zum Scheitern verurteilt ist. Es handelt sich nicht um ein technisches Problem, das sich mit mehr Rechenleistung oder besseren Algorithmen lösen ließe. Es ist eine mathematische Grenze, so unverrückbar wie die Tatsache, dass sich ein Kreis nicht quadrieren lässt.

Das bedeutet nicht, dass statische Analyse nutzlos wäre. Linter und Werkzeuge zur statischen Codeanalyse finden sehr wohl Fehler, und sie finden sie zuverlässig. Aber sie beschränken sich auf bestimmte Muster, auf bekannte Fehlerklassen und eingeschränkte Programmstrukturen. Sie tauschen Vollständigkeit gegen Anwendbarkeit ein. Ein Analysator, der Null-Pointer-Dereferenzierungen in Java findet, löst nur ein sorgfältig eingegrenztes Teilproblem. Das ist nützlich und wichtig, aber es ist etwas fundamental anderes als ein Werkzeug, das garantiert alle Bugs findet.

Was formale Verifikation leisten kann

Angesichts dieser Grenzen stellt sich die Frage, wieso es formal verifizierte Software gibt. Der Mikrokernel seL4 etwa wurde mathematisch als korrekte Implementierung seiner Spezifikation bewiesen. Der C-Compiler CompCert wurde verifiziert, dass er die Semantik des Quellcodes beim Kompilieren korrekt erhält. Diese Projekte existieren, und sie funktionieren. Widersprechen sie nicht dem, was gerade dargelegt wurde?

Die Antwort liegt in den Einschränkungen, die formale Verifikation voraussetzt. seL4 umfasst etwa 10.000 Zeilen C-Code. Der Beweis seiner Korrektheit erforderte einen Aufwand, der auf etwa zwanzig Personenjahre geschätzt wird. Das ist ein Verhältnis von ungefähr zwei Personenjahren pro tausend Zeilen Code, das für eine typische Geschäftsanwendung mit Hunderttausenden oder Millionen von Codezeilen schlicht nicht tragbar ist. Selbst in Branchen, in denen Softwarefehler Menschenleben kosten können, wird formale Verifikation nur auf kleine, besonders kritische Komponenten angewendet.

Formale Verifikation beweist zudem immer nur die Korrektheit relativ zu einer Spezifikation. Sie sagt: „Dieses Programm verhält sich exakt so, wie die Spezifikation es beschreibt.“ Sie sagt nicht: „Die Spezifikation beschreibt das Richtige.“ Wenn die Spezifikation einen Fehlerfall nicht berücksichtigt, etwa die Möglichkeit, dass stdout auf eine volle Festplatte zeigt, oder dass ein Browser bestimmte Ports blockiert, dann ist das verifizierte Programm korrekt im formalen Sinne und trotzdem fehlerhaft im praktischen. Die Spezifikation zu schreiben ist selbst ein kreativer Akt, der denselben Unvollständigkeiten unterliegt wie die Softwareentwicklung insgesamt. Das Problem verschiebt sich also lediglich, es löst sich nicht auf.

Formale Verifikation hat außerdem eine Grenze, die direkt aus dem Halteproblem folgt: Sie lässt sich nicht vollständig automatisieren. Für jeden Beweis sind menschliche Einsichten nötig, Invarianten und Induktionsargumente, die eine Maschine nicht allgemein selbst finden kann. Das macht formale Verifikation zu einem mächtigen Werkzeug für sicherheitskritische Kernkomponenten, aber nicht zu einer skalierbaren Lösung für Software im Allgemeinen.

Fehlerfreiheit ist kein realistisches Ziel

Vom Hello-World-Bug über die Port-6000-Überraschung bis zum Halteproblem zeigt sich ein durchgängiges Bild: Vollständige Fehlerfreiheit in Software ist kein erreichbares Ziel. Das liegt nicht an mangelnder Sorgfalt oder unzureichenden Werkzeugen. Es liegt an mathematischen Grenzen, die für alle Programme gelten, und an der Natur von Tests als Stichproben, die niemals alle Lücken zwischen Annahmen und Realität schließen können.

Diese Erkenntnis ist kein Grund für Fatalismus, aber sie verlangt einen Wechsel der Perspektive. Die Frage sollte nicht lauten „Wie eliminieren wir alle Bugs?“, sondern „Wie gehen wir damit um, dass Bugs unvermeidlich sind?“. Die Antworten darauf sind bekannt: Defense in Depth, also mehrere unabhängige Schutzschichten statt einer einzigen, sodass der Fehler in einer Schicht von einer anderen aufgefangen wird. Monitoring und Alerting, um Fehler in Produktion schnell zu erkennen, statt darauf zu hoffen, dass es keine gibt. Fehlertolerante Architekturen, die mit dem Ausfall einzelner Komponenten umgehen können, ohne dass das Gesamtsystem zusammenbricht. Und schnelle Recovery-Prozesse, weil die Frage nicht ist, ob etwas schiefgeht, sondern wann.

Netflix hat mit dem Chaos-Monkey-Ansatz vorgemacht, wie das aussehen kann: Wenn regelmäßig absichtlich Komponenten abgeschaltet werden, ist das System gezwungen, mit Ausfällen umzugehen, und die Fehlertoleranz wird zum integralen Bestandteil der Architektur statt zum nachträglichen Zusatz.

Wer akzeptiert, dass Fehlerfreiheit eine Illusion ist, kann paradoxerweise also zuverlässigere Software bauen: durch Systeme, die mit Fehlern rechnen und trotzdem funktionieren. Die Mathematik hat der Softwarebranche eine harte Grenze gesetzt. Aber innerhalb dieser Grenze liegt noch sehr viel Raum für bessere Software, solange niemand den Fehler macht, Perfektion für ein erreichbares Ziel zu halten.

Das Halteproblem ist jedoch nicht die einzige fundamentale Grenze, an die Softwareentwicklung stößt. Sobald mehrere Rechner zusammenarbeiten sollen, taucht eine andere harte Grenze auf, die ebenso unveränderlich ist und in der Praxis ebenso oft unterschätzt wird. Der nächste Teil dieser Serie untersucht, warum verteilter Konsens so schwer ist und unter bestimmten Bedingungen sogar nachweislich unmöglich.


(who)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Proxmox Datacenter Manager 1.1 wird Schweizer Taschenmesser für Proxmox-Cluster


Die Wiener Proxmox Server Solutions GmbH hat ihren Proxmox Datacenter Manager 1.1 veröffentlicht. Der Datacenter Manager bietet eine zentrale, einheitliche Web-Konsole, um alle Instanzen des Proxmox Virtual Environment (VE) und des Proxmox Backup Servers zu managen. Der gesamte Cluster samt aller Nodes kann so organisationsübergreifend verwaltet, überwacht und skaliert werden. Die neue Version 1.1 des Proxmox Datacenter Managers bietet automatisierte Workflows für das Ausrollen von Nodes, eine umfassende Subskriptions-Verwaltung, ein einheitliches Ceph-Cluster-Monitoring sowie ein erweitertes, zentrales Gast- und Snapshot-Management.

Weiterlesen nach der Anzeige

Mit Version 1.1 erweitert der Proxmox Datacenter Manager seine Rolle zum zentralen Konfigurationsserver für automatisiertes Host-Provisioning in verteilten Infrastrukturen. Administratoren können sogenannte Antwortdateien mit vordefinierten Installationsparametern zentral verwalten und für das unbeaufsichtigte Ausrollen neuer Hosts bereitstellen. Die Abläufe sind über den neuen Bereich „Automatische Installationen“ im Reiter „Remotes“ direkt im Webinterface erreichbar. Dort lässt sich auch der Fortschritt laufender Installationen in Echtzeit überwachen.

Für die Absicherung des Provisioning-Prozesses setzt Proxmox auf einen tokenbasierten Mechanismus: Nur autorisierte Zielsysteme erhalten Zugriff auf die hinterlegten Konfigurationen. Damit adressiert Proxmox vor allem größere Cluster- und Edge-Szenarien, in denen konsistente Rollouts und zentrale Verwaltung entscheidend sind. Wie das aktuelle Proxmox Virtual Environment 9.2 basiert auch der Proxmox Datacenter Manager 1.1 auf Debian GNU/Linux 13.5 „Trixie“ mit Linux-Kernel 7.0 inklusive aktualisierter Pakete und Bugfixes sowie OpenZFS 2.4.2.

Zentrale Verwaltung von Subskriptionen

Ebenfalls neu im Proxmox Datacenter Manager 1.1 ist eine zentrale Subscription-Registry, um die Verwaltung von Lizenzschlüsseln in verteilten Infrastrukturen zu vereinfachen. Administratoren können Subscription-Keys zentral vorhalten, einzelnen Remotes zuweisen und bei Bedarf wieder entkoppeln. Das reduziert den Verwaltungsaufwand insbesondere in Multi-Site-Umgebungen mit vielen Hosts. Zudem lassen sich Subscription-Keys direkt in vorbereitete Antwortdateien integrieren. Neue Hosts registrieren ihre Subscription damit automatisch bereits während der Installation. Die Funktion verzahnt Lizenzmanagement und automatisiertes Provisioning und soll konsistente Deployments in größeren Proxmox-Umgebungen erleichtern.

Der Proxmox Datacenter Manager 1.1 erweitert das Monitoring verteilter, hyperkonvergenter Infrastruktur-Umgebungen (HCI) um eine native Überwachung angebundener Ceph-Cluster. Administratoren erhalten über ein zentrales Dashboard konsolidierte Einblicke in Zustand, Kapazität und Echtzeit-Performance mehrerer Cluster. Die einheitliche Ansicht erleichtert insbesondere den Betrieb verteilter Proxmox-VE-Infrastrukturen und reduziert den Aufwand für die Analyse einzelner Standorte. Darüber hinaus liefert das Monitoring detaillierte Statusinformationen zu Object Storage Daemons (OSDs), Monitoren, Managern, Metadata Servern (MDS), Storage-Pools, CephFS sowie relevanten Cluster-Flags. Damit adressiert Proxmox vor allem Betreiber größerer HCI-Deployments mit hohen Anforderungen an Transparenz und Betriebsüberwachung.

Zentrales Guest- und Snapshot-Management

Weiterlesen nach der Anzeige

Mit Version 1.1 legt der Proxmox Datacenter Manager den Grundstein für ein zentrales Guest-Management über mehrere Remotes hinweg. Virtuelle Maschinen auf Basis von QEMU sowie LXC-Container lassen sich nun in einer gemeinsamen Ansicht verwalten, wahlweise als sortierbare Tabelle oder in einer nach Remotes strukturierten Baumansicht. Textfilter erleichtern die Suche nach einzelnen Gästen, während häufig genutzte Aktionen direkt aus der Übersicht heraus verfügbar sind.

Neu hinzu kommt ein zentrales Snapshot-Management: Snapshots lassen sich in einer Parent-Child-Struktur anzeigen, erstellen, wiederherstellen oder löschen. Auch das Bearbeiten von Beschreibungen ist möglich. Ergänzend führt Proxmox den Befehl „Resume“ für pausierte oder suspendierte QEMU-VMs ein. Die Funktionen markieren den ersten Schritt hin zu einer umfassenderen Guest-Orchestrierung, die in kommenden Releases weiter ausgebaut werden soll.

Preise und Verfügbarkeit

Geplante Funktionen sowie alle Verbesserungen und Neuerungen des Proxmox Datacenter Managers 1.1 beschreibt dessen Roadmap detailliert. Der Proxmox Datacenter Manager 1.1 steht als Open-Source-Software ab sofort zum Download bereit und kann kostenlos eingesetzt werden. Die Software selbst ist kostenlos, ihr Einsatz erfordert allerdings aktive Enterprise Support Subscriptions für alle verwalteten Produkte.


(axk)



Source link

Weiterlesen

Entwicklung & Code

AWS Sovereign Cloud: KI-Ausbau und neue Agenten-Tools


Für die kommenden Monate kündigte Amazon auf dem AWS Summit einen deutlichen Ausbau des KI-Angebots in der European Sovereign Cloud an. Neu hinzu kommen sollen Amazon Nova 2 Lite sowie Open-Weight-Modelle von Mistral AI und OpenAI auf Amazon Bedrock. Damit weitet AWS die Modellauswahl in der als souverän beworbenen Cloud auf eine Bandbreite aus, die bisher nur in den klassischen Regionen verfügbar war.

Weiterlesen nach der Anzeige

Mantle soll Bedrock für sensible Workloads absichern

Architektonisch interessant ist Mantle, die Inferencing-Engine der nächsten Generation für Amazon Bedrock. AWS verspricht Zero Operator Access: Das Betriebspersonal soll Eingaben und Antworten zu keinem Zeitpunkt einsehen können – relevant für Workloads mit Berufsgeheimnis oder strengen Datenschutzanforderungen. Zusätzlich soll Mantle Anfragen dynamisch Kapazitäten zuweisen, was die Verfügbarkeit für Steady-State-Workloads verbessert und schnelles Skalieren bei Lastspitzen erlaubt.

Die seit Januar 2026 allgemein verfügbare AWS European Sovereign Cloud ist ein vollständig in der EU betriebenes Cloud-Angebot mit Datenresidenz, ausschließlich EU-ansässigem Betriebspersonal und eigener Konzernstruktur unter deutschem Recht. AWS investiert dafür 7,8 Milliarden Euro bis 2040. Die erste Region steht in Brandenburg; Local Zones in Belgien, den Niederlanden und Portugal sind geplant. Die deutsche Trägergesellschaft leitet Kathrin Renz; das Gesamtangebot verantwortet Stéphane Israël, zuvor CEO von Arianespace.

Der AWS Marketplace umfasst nach AWS-Angaben über 165 für die European Sovereign Cloud optimierte Lösungen aus Infrastruktur, DevOps, Cloud Operations und KI-Agenten. Neu allgemein verfügbar ist SAP Cloud ERP Private. Neu auf der Infrastrukturseite sind Amazon EC2 G6-Instanzen mit NVIDIA-L4-GPUs für beschleunigtes Computing; zuvor sind bereits AWS Network Firewall, AWS Elastic Disaster Recovery und das AWS IAM Identity Center eingezogen.

Agentenbasierte Werkzeuge: Kiro, Quick und Transform

Den zweiten Schwerpunkt setzte Jonathan Allen, Executive in Residence bei AWS, mit einer Bestandsaufnahme zur agentenbasierten Software-Entwicklung: Wer mit KI-Agenten Code zehnmal schneller produziert, verlagert den Aufwand auf Verifikation und Betrieb. AWS adressiert das mit drei Produktlinien.

Kiro ist eine agentenbasierte Entwicklungsumgebung, seit November 2025 allgemein verfügbar. Sie folgt einem spezifikationsgetriebenen Ansatz: User Stories, Designdokumente und Architekturskizzen entstehen als strukturierte Specs, gegen die der Agent dann implementiert. Mit der GA kamen Property-based Testing zur Spec-Konformität, Checkpointing, eine Kiro-CLI sowie zentral verwaltbare Team-Pläne über das AWS IAM Identity Center hinzu. Im Backend nutzt Kiro Anthropic Claude (zuletzt Opus 4.7).

Weiterlesen nach der Anzeige

Seit der GA hat AWS auf Kiro spürbar Tempo gemacht. Wenige Tage vor dem Summit, am 12. Mai, ergänzte AWS Kiro um eine optionale Requirements-Analysis-Engine, die vor jeder Code-Generierung prüft, ob eine Spec überhaupt widerspruchsfrei umsetzbar ist. Eine dreistufige neurosymbolische Pipeline – Refinement, Auto-Formalisierung, logische Analyse – überführt natürlichsprachliche Anforderungen über die EARS-Notation in formale SMT-lib-Logik; ein automatisierter Reasoner sucht darauf nach Widersprüchen, Lücken sowie zulässigen und unzulässigen Verhaltensszenarien. Mehrdeutigkeiten erkennt Kiro über die semantische Entropie mehrerer LLM-Übersetzungsproben: Divergieren die Formalisierungen logisch, präsentiert Kiro die Stelle als Zwei-Optionen-Frage („remove the record“ – Hard- oder Soft-Delete?). Den technischen Unterbau hat ein AWS-Applied-Science-Team in einem detaillierten zweiten Blogpost dokumentiert und mit aktueller Requirements-Engineering-Forschung untermauert.

Im selben Release beschleunigt Parallel Task Execution die Implementierungsphase: Kiro analysiert den Abhängigkeitsgraphen einer Spec, bündelt unabhängige Tasks zu parallel laufenden „Waves“ mit isoliertem Kontext und arbeitet fehlertolerant weiter, wenn ein einzelner Task scheitert – Verkürzung großer Specs laut AWS von 60 bis 90 Minuten auf etwa 15 Minuten. Ein neuer Quick-Plan-Modus scannt vorab Sprache, Frameworks und Projektstruktur des Workspace und stellt darauf zugeschnittene Klärungsfragen am Anfang, statt jeden Spec-Schritt einzeln freigeben zu lassen.

Ferner brachte die Kiro CLI 2.4.0 einen /rewind-Befehl zum Verzweigen aus früheren Prompts, eine modellindividuell einstellbare Reasoning-Tiefe und laut AWS eine um 88 Prozent schnellere Workspace-Initialisierung. Compliance-seitig ist Kiro seit Februar in den AWS-GovCloud-Regionen (US-East/West) verfügbar und seit Mai HIPAA-eligible – allerdings nur IDE und CLI, Kiro Web ist (noch) nicht enthalten. Parallel füllt sich der Marktplatz „Kiro Powers“: AWS Observability hängt Incident-Investigationen per Klick an Kiro an, ein Apache-Spark-Troubleshooting- und ein Upgrade-Agent für Amazon EMR sollen Spark-Versionssprünge von Monaten auf Wochen verkürzen.

Quick und Transform für Unternehmensanwendungen

AWS positioniert Amazon Quick als Weiterentwicklung von Amazon Q Business, der Assistent verknüpft strukturierte und unstrukturierte Unternehmensdaten. AWS Transform richtet sich an klassische Modernisierungsprojekte; AWS nennt über eine Milliarde transformierte Mainframe-Code-Zeilen als Referenzgröße. Neu ist vor allem, wo Transform künftig läuft: AWS hat die Modernisierungsagenten Mitte Mai aus der eigenen Web-Konsole herausgelöst und über einen AWS-Transform-MCP-Server, Agent-Plugins und eine Kiro Power direkt in agentische Entwicklungsumgebungen wie Kiro, Claude, Cursor und Codex gebracht. Eine Transformation lässt sich damit in der IDE starten, im Web-Frontend überwachen und wieder in der IDE fortsetzen – gegen denselben Job mit konsistentem Zustand und nun auch per IAM-Rollen-Authentifizierung statt separater Anmeldung.

Mit AWS Transform Custom lassen sich eigene Transformationsagenten für unternehmenseigenen Code bauen. Das dafür nötige Agent-Builder-Toolkit namens Kiro power ist seit Mai allgemein verfügbar und erlaubt Partnern und Kunden, eigene Agenten samt Tools, Wissensbasen und Workflows in Transform einzuklinken und zur Wiederverwendung zu registrieren. Konkreter wird auch die VMware-Migration: Transform modernisiert jetzt Netzwerke mit, gleicht geplante VPCs gegen bereits vorhandene ab, erkennt CIDR-Konflikte vor dem Provisioning und verarbeitet Netzkonfigurationen unabhängig vom Quellwerkzeug.

Ergänzend bewirbt AWS dedizierte DevOps- und Security-Agenten, die Incidents automatisch untersuchen, Ursachen diagnostizieren und Fixes vorschlagen – die finale Freigabe bleibt beim Menschen. Unterfüttert wird der Agenten-Stack durch weitere Modelloptionen: In Amazon SageMaker JumpStart sind seit Mai unter anderem GLM-5.1-FP8 von Z.ai (ausgelegt auf langlaufendes, agentisches Coding über viele Iterationen) sowie das kompakte Phi-4-mini-instruct von Microsoft (Reasoning unter Latenz- und Speicherrestriktionen, 24 Sprachen) verfügbar – per Klick oder SDK im eigenen AWS-Konto deploybar.

Präsentiert hatte Amazon die Neuerungen im Rahmen des AWS Summit. Mit 8800 Teilnehmern, 101 Sponsoren und 156 Sessions zog die Hausmesse dieses Jahr ein breites Fachpublikum in die Hamburg Messe.


(fo)



Source link

Weiterlesen

Entwicklung & Code

DNS-AID: Telefonbuch für KI-Agenten | heise online


Die Linux Foundation hat das Open-Source-Projekt DNS-AID (DNS for AI Discovery) angekündigt. Es soll KI-Agenten und agentenbasierte Dienste über die bestehende DNS-Infrastruktur auffindbar und deren Identität überprüfbar machen. Statt auf zentrale Verzeichnisse oder fest konfigurierte Endpunkte zu setzen, greift DNS-AID auf etablierte Internetstandards und die dezentrale Struktur des Domain Name System (DNS) zurück.

Weiterlesen nach der Anzeige

DNS-AID umfasst ein offenes Protokoll und eine Referenzimplementierung, um KI-Agenten zu veröffentlichen, zu suchen und zu verifizieren. Ursprünglich entwickelte Infoblox das Projekt, das nun unter dem Dach der Linux Foundation weiterläuft. Parallel dazu erarbeitet die IETF die technische Spezifikation als Internet-Draft. Ziel ist ein standardisiertes Verfahren, mit dem KI-Agenten die Dienste anderer Agenten automatisch finden und nutzen können.

Veröffentlichung über DNS-Einträge

Im Kern veröffentlicht DNS-AID Informationen zu Agenten als DNS-Einträge innerhalb einer Domain. Betreiber registrieren ihre Agenten nach dem Schema _._._agents. in ihrer DNS-Zone – etwa _chatbot._mcp._agents.example.com für einen MCP-basierten Chatbot. Andere Agenten ermitteln diese Informationen anschließend über reguläre DNS-Abfragen und kommunizieren direkt mit dem Zielsystem. Die Projektseite beschreibt das Vorgehen als universelles Discovery-Verfahren für Agenten, vergleichbar mit der Namensauflösung von Websites über DNS.

Nach Angaben der Entwickler kommt DNS-AID dabei ohne neue DNS-Record-Typen aus. Das Projekt stützt sich auf bestehende Mechanismen wie Service Binding Records (SVCB, RFC 9460), TXT-Records sowie die Sicherheitsstandards DNSSEC und DANE/TLSA. SVCB-Records liefern ursprünglich zusätzliche Verbindungsinformationen zu Netzwerkdiensten. DNS-AID nutzt SVCB-Records, um Agenten samt Endpunkt, Protokollangaben und Verweisen auf weitere Metadaten zu veröffentlichen. Fähigkeiten können je nach Implementierung direkt über DNS-Einträge oder über verknüpfte Dokumente bereitgestellt werden.

Drei Wege zur Auffindung

Agenten lassen sich auf drei Wegen auffinden: über ihren Namen, über bestimmte Fähigkeiten oder über einen vollständigen Katalog aller Agenten einer Domain. Die Suche nach Fähigkeiten eignet sich etwa, um innerhalb einer Organisation oder zwischen Partnerunternehmen einen Agenten für Aufgaben wie Terminplanung, Support oder Buchungen zu finden. Alternativ rufen Systeme einen Index-Eintrag ab, der sämtliche veröffentlichten Agenten einer Domain auflistet.

Für die Vertrauensprüfung greift DNS-AID auf die bestehende DNS-Sicherheitsinfrastruktur zurück. Öffentliche DNS-Zonen sollen mit DNSSEC signiert sein, damit Clients die Authentizität der Einträge kryptografisch prüfen können. Optional verknüpfen TLSA-Einträge nach dem DANE-Verfahren TLS-Zertifikate direkt mit DNS-Einträgen. So entsteht nach Vorstellung der Entwickler eine durchgehende Vertrauenskette von der DNS-Root-Zone bis zum einzelnen Agenten.

Weiterlesen nach der Anzeige

Protokollunabhängig und mit Referenzimplementierung

Auf eine bestimmte Form der Agentenkommunikation legt sich das Protokoll nicht fest. Genannt werden unter anderem MCP, Agent-to-Agent-Protokolle (A2A) und HTTPS. Weitere Protokolle lassen sich über ALPN-IDs in den SVCB-Einträgen einbinden. ALPN (Application-Layer Protocol Negotiation) dient bereits heute etwa zur Aushandlung von HTTP/2 oder HTTP/3.

Eine Referenzimplementierung steht mit einem Python-SDK, einem CLI-Tool und einem MCP-Server bereit. Sie unterstützt verschiedene DNS-Backends, darunter Cloudflare, AWS Route 53, NS1, Google Cloud DNS und Infoblox NIOS sowie alle DNS-Server, die RFC 2136 (Dynamic DNS) beherrschen. Zudem enthält sie Funktionen, um Agenten zu veröffentlichen und zu suchen sowie DNSSEC- und DANE-Informationen zu validieren.

Die Linux Foundation bezeichnet DNS-AID explizit als offenen und herstellerneutralen Ansatz für das Auffinden von Agenten. Zu den ersten Unterstützern zählen Cloudflare, CSC, Equinix, GoDaddy, Indeed, Infoblox, das Internet Systems Consortium (ISC) und WWT.


(fo)



Source link

Weiterlesen

Beliebt