Connect with us

Entwicklung & Code

Ein Claude-Code-Plug-in in einem Nachmittag: Was ich dabei gelernt habe


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Wenn jemand sagt, man solle ein Plug-in für ein KI-Tool entwickeln, denken die meisten an SDKs, an Boilerplate-Code, an Dokumentationen, die man erst dreimal lesen muss, bevor man den Einstiegspunkt findet. Ich hatte dieselbe Erwartung, als ich mich vor ein paar Wochen entschieden habe, ein Plug-in für Claude Code zu bauen. Claude Code ist Anthropics Kommandozeilen-Tool für KI-gestützte Softwareentwicklung, und seit einiger Zeit lassen sich dafür eigene Plug-ins entwickeln und über einen Marketplace verteilen.

Weiterlesen nach der Anzeige


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.

Das Plug-in, das ich gebaut habe, bindet EventSourcingDB an, eine Datenbank, die speziell für Event Sourcing konzipiert ist. Der Vollständigkeit halber: EventSourcingDB ist ein Produkt meines Unternehmens, der the native web GmbH. Dieser Blogeintrag ist jedoch kein Text über die Datenbank, sondern über das, was ich beim Entwickeln des Plug-ins gelernt habe. Die Datenbank dient lediglich als konkretes Beispiel, an dem sich die Erkenntnisse nachvollziehen lassen.

Was Claude-Code-Plug-ins eigentlich sind

Bevor ich auf das Plug-in selbst eingehe, lohnt sich eine kurze Einordnung. Denn Claude-Code-Plug-ins sind nicht das, was man vielleicht erwartet, wenn man den Begriff „Plug-in“ hört.

In der Welt der KI-gestützten Entwicklungstools hat sich in den vergangenen Monaten vor allem ein Standard etabliert: das Model Context Protocol, kurz MCP. MCP-Server stellen einem KI-Modell Werkzeuge zur Verfügung, die es aufrufen kann. Das Modell entscheidet selbst, wann welches Werkzeug sinnvoll ist, und ruft die entsprechende Funktion auf. Für EventSourcingDB gibt es bereits einen solchen MCP-Server. MCP-Server sind mächtig, erfordern aber eine gewisse Infrastruktur: Man braucht einen laufenden Serverprozess, eine Transportschicht und eine Tooldefinition im JSON-Schema-Format.


GenAI Summit, Linien

GenAI Summit, Linien

(Bild: TechSolution/Adobe Stock)

GenAI verändert die Softwareentwicklung grundlegend und hat sich im Arbeitsalltag vieler Developer etabliert. Die KI-Tools übernehmen dabei nicht nur lästige Tipparbeit, sondern helfen bei komplexen Aufgaben. Um sicheren und effizienten Code zu erhalten, muss man aber auch ihre Risiken kennen.

Der betterCode() GenAI Summit zeigt am 11. Juni, welche KI-Tools für welche Aufgaben geeignet sind und wie die KI-Integration effizient funktioniert. Außerdem thematisiert er die Auswirkungen auf die Arbeit von Entwicklungsteams.

Claude-Code-Plug-ins verfolgen einen anderen Ansatz. Sie erweitern Claude Code nicht durch laufende Prozesse, sondern durch sogenannte Skills (genau genommen kann ein Plug-in neben Skills noch andere Dinge enthalten, aber für mein Beispiel beschränke ich mich auf sie). Ein Skill ist dabei im Kern eine Textdatei, die Claude Code erklärt, wie es eine bestimmte Aufgabe erledigen soll. Das klingt zunächst unspektakulär, ist aber bemerkenswert effektiv. Statt einer programmatischen Schnittstelle erhält das Modell eine natürlichsprachliche Anleitung, die es interpretiert und umsetzt. Plug-ins lassen sich über einen Marketplace installieren und verteilen, sodass andere Entwicklerinnen und Entwickler sie einfach nutzen können.

Weiterlesen nach der Anzeige

Die Anatomie eines Plug-ins

Was mich am meisten überrascht hat, war die Struktur eines Plug-ins. Oder besser gesagt: wie wenig Struktur nötig ist. Die Verzeichnisstruktur des EventSourcingDB-Plug-ins sieht beispielsweise folgendermaßen aus:


/
  .claude-plugin/
    marketplace.json
  plugins/
    esdb/
      .claude-plugin/
        plugin.json
      skills/
        ping/
          SKILL.md
        write-events/
          SKILL.md
        read-events/
          SKILL.md
        ...


Das ist die gesamte Struktur. Kein SDK, kein Framework, kein Build-Schritt. Im Kern besteht ein Plug-in aus zwei Dingen: einer Plug-in.json und einer Sammlung von SKILL.md-Dateien.

Die plugin.json ist das Manifest. Sie definiert den Namen, die Version und eine kurze Beschreibung. Das sieht für das EventSourcingDB-Plug-in in etwa so aus:


{
  "name": "esdb",
  "version": "1.0.0",
  "description": "Interact with EventSourcingDB using its HTTP API",
  "author": {
    "name": "the native web GmbH",
    "email": "hello@thenativeweb.io"
  }
}


Jeder Skill liegt in einem eigenen Unterverzeichnis und besteht aus einer eigenen SKILL.md-Datei. Diese Datei beginnt mit einem Frontmatter-Block, der den Namen und eine Beschreibung enthält, gefolgt von den eigentlichen Anweisungen in natürlicher Sprache:


---
name: ping
description: Check whether an EventSourcingDB instance is reachable.
---

# Ping

Send a GET request to $ESDB_URL/api/v1/ping to check whether
the EventSourcingDB instance is reachable. No authentication
is required for this endpoint. A successful response returns
HTTP 200 with the text "OK".


Das ist, in vereinfachter Form, der gesamte Ping-Skill. Claude Code liest diese Beschreibung und setzt sie eigenständig um. Es generiert den HTTP-Aufruf, sendet ihn und interpretiert die Antwort. Die eigentliche Logik steckt nicht in ausführbarem Code, sondern in einer präzisen Beschreibung. Die Qualität des Plug-ins hängt damit nicht von der Qualität des Codes ab, sondern von der Qualität der Beschreibung.

Auf der Ebene darüber liegt die marketplace.json. Sie beschreibt, welche Plug-ins ein Marketplace anbietet. Claude Code hat einen offiziellen Marketplace, der von Anthropic verwaltet wird und geprüfte Plug-ins enthält. Darüber hinaus kann aber jede Person und jede Organisation einen eigenen Marketplace erstellen. Es genügt ein GitHub-Repository mit einer marketplace.json im Verzeichnis .claude-Plug-in. Das war für mich ein entscheidender Punkt: Man ist nicht auf eine zentrale Instanz angewiesen, sondern kann Plug-ins auch intern oder für die eigene Community bereitstellen, ohne einen Freigabeprozess durchlaufen zu müssen.

Für jemanden wie mich, der seit über zwanzig Jahren Software entwickelt, ist die Art der Plug-in-Entwicklung ein bemerkenswerter Perspektivwechsel. Statt in Funktionen und Klassen zu denken, denkt man in Erklärungen und Anleitungen. Statt eine API zu implementieren, beschreibt man eine API. Die Fähigkeit, präzise und unmissverständlich zu formulieren, wird zur eigentlichen Entwicklungskompetenz.

Vom leeren Verzeichnis zum funktionierenden Plug-in

Wie sah nun der praktische Weg aus? Ich habe mit einem leeren Repository und der Frage begonnen, welche Interaktionen mit EventSourcingDB ich abbilden wollte. Die Datenbank bietet eine HTTP-API mit einer überschaubaren Anzahl von Endpunkten: Events schreiben, Events lesen, Events beobachten, Subjects abfragen, Event-Typen auflisten, EventQL-Queries ausführen und Schemas registrieren. Dazu kommen administrative Funktionen wie Ping und die Verifikation des API-Tokens.

Für jeden dieser Endpunkte habe ich einen eigenen Skill angelegt. Das klingt nach viel Arbeit, war es aber nicht. Zum einen folgt nämlich jeder Skill demselben Muster: eine kurze Beschreibung des Zwecks, die relevanten API-Endpunkte mit ihren Parametern, Hinweise zur Authentifizierung und Beispiele für typische Aufrufe und Antworten. Die Markdown-Dateien sind jeweils zwischen rund 30 und 80 Zeilen lang. Zum anderen habe ich auch dazu wiederum Claude Code genutzt: Ich habe die Skills also nicht von Hand geschrieben, sondern Claude Code jeweils beschrieben, was ich erreichen möchte und die Skills anschließend generieren lassen.

Der erste Skill, den ich auf diesem Weg erstellt habe, war der einfachste: der oben bereits erwähnte Ping-Skill. Dieser Skill prüft, ob eine EventSourcingDB-Instanz erreichbar ist. Die zugehörige Beschreibung umfasst kaum mehr als den API-Endpunkt, die erwartete Antwort und einen Hinweis, dass keine Authentifizierung nötig ist. Innerhalb weniger Minuten war der Skill fertig, und Claude Code konnte ihn verwenden.

Was mich überrascht hat: Es funktionierte auf Anhieb. Kein Debugging, kein Trial-and-Error, kein stundenlanges Nachjustieren. Claude Code las die Beschreibung, verstand die Aufgabe und führte den HTTP-Aufruf korrekt aus. Ermutigt durch diesen schnellen Erfolg habe ich die weiteren Skills in rascher Folge geschrieben. Nach einem Nachmittag war das Plug-in vollständig.

Das soll nicht den Eindruck erwecken, es hätte keinerlei Herausforderungen gegeben. Die Beschreibung des Skills für das Beobachten von Events erforderte mehr Sorgfalt, weil hier eine langlebige HTTP-Verbindung mit NDJSON-Streaming im Spiel ist. Ich musste Claude Code erklären, dass die Verbindung offen bleibt und kontinuierlich Daten liefert. Aber auch das war eine Frage der richtigen Formulierung, nicht der richtigen Implementierung.

Was das Plug-in kann und wie es funktioniert

Das fertige Plug-in umfasst zehn Skills, die fast die gesamte HTTP-API von EventSourcingDB abdecken. Die Installation erfolgt in zwei Schritten. Zunächst fügt man den Marketplace hinzu:

/plugin marketplace add thenativeweb/claude-plugins

Anschließend installiert man das Plug-in:

/plugin install esdb@thenativeweb

Danach stehen die Skills zur Verfügung. Jeder Skill hat einen Namespace-Präfix, der sich aus dem Plug-in-Namen ergibt, und wird als Slash-Command aufgerufen. Um etwa die Erreichbarkeit einer EventSourcingDB-Instanz zu prüfen, genügt:

/esdb:ping

Für komplexere Interaktionen übergibt man Argumente in natürlicher Sprache. Ein Aufruf wie:

/esdb:write-events Schreibe ein Event vom Typ „io.eventsourcingdb.library.book-acquired“ für das Subject „/books/42“ mit den Daten title „2001“, author „Arthur C. Clarke“

veranlasst Claude Code, den passenden HTTP-Request zu konstruieren und an die Datenbank zu senden. Das Modell interpretiert die natürlichsprachliche Beschreibung, bildet sie auf die API-Parameter ab und gibt das Ergebnis lesbar aus. Dasselbe gilt für EventQL-Queries, bei denen Claude Code die Abfrage auf Basis der Skill-Beschreibung in das richtige Format übersetzt.

Besonders aufschlussreich war die Arbeit an den Skills für das Lesen und Beobachten von Events. Beide nutzen denselben Endpunkt, unterscheiden sich aber in ihrem Verhalten: Lesen liefert eine endliche Menge von Events und schließt die Verbindung, Beobachten hält die Verbindung offen und streamt neue Events in Echtzeit. Diese Unterscheidung musste in der Beschreibung klar herausgearbeitet werden, weil Claude Code sonst nicht wüsste, wann es die Verbindung schließen soll und wann nicht.

Hier zeigt sich ein wichtiges Muster: Die Qualität eines Skills hängt davon ab, wie gut man die Semantik einer Aktion beschreiben kann. Es reicht nicht, die technischen Parameter eines API-Aufrufs aufzulisten. Man muss dem Modell das Warum und das Wann vermitteln, nicht nur das Wie. Das ist eine andere Art zu denken als beim klassischen Programmieren, und sie erfordert eine andere Art von Sorgfalt.

Die Konfiguration des Plug-ins erfolgt über Umgebungsvariablen. Die URL der EventSourcingDB-Instanz und der API-Token werden beim Start gesetzt, und die Skills referenzieren diese Werte in ihren Beschreibungen. Auch das ist bemerkenswert einfach: keine Konfigurationsdateien, keine verschachtelten Einstellungen, keine Initialisierungslogik.

Plug-ins als Brücke zwischen KI und Fachdomäne

Was lässt sich aus dieser Erfahrung verallgemeinern? Drei Beobachtungen erscheinen mir besonders relevant.

Erstens: Die Einstiegshürde für Claude-Code-Plug-ins ist bemerkenswert niedrig. Wer eine HTTP-API hat und sie in natürlicher Sprache beschreiben kann, kann ein Plug-in bauen. Es sind keine besonderen Programmierkenntnisse nötig, kein Verständnis von Compiler-Infrastruktur, keine Erfahrung mit Plug-in-Architekturen. Die einzige Voraussetzung ist die Fähigkeit, präzise zu formulieren, was eine Aktion tut, welche Eingaben sie erwartet und welche Ausgaben sie liefert. Das macht die Plug-in-Entwicklung zugänglich für eine breite Gruppe von Entwicklerinnen und Entwicklern.

Zweitens: Skills als natürlichsprachliche Beschreibungen sind ein ungewöhnlich mächtiges Konzept. Sie ermöglichen es, domänenspezifisches Wissen in ein KI-Tool einzubringen, ohne eine einzige Zeile ausführbaren Code zu schreiben. Das verschiebt die Kernkompetenz: Nicht die Implementierung ist entscheidend, sondern das Verständnis der Domäne und die Fähigkeit, dieses Verständnis klar auszudrücken. Für Teams, die mit fachlich komplexen Systemen arbeiten, ist das ein interessanter Ansatz, weil er die Brücke zwischen Fachexpertise und Werkzeugentwicklung verkürzt.

Drittens: Die Grenze zwischen Plug-ins und MCP-Servern verschwimmt, und das ist beabsichtigt. Plug-ins eignen sich gut für Szenarien, in denen ein KI-Tool eine bestehende API nutzen soll und die Interaktion über natürliche Sprache gesteuert wird. MCP-Server sind die bessere Wahl, wenn man programmatische Kontrolle braucht, etwa für komplexe Authentifizierungsflüsse, zustandsbehaftete Sitzungen oder bidirektionale Kommunikation. Beide Ansätze ergänzen sich, und für viele Systeme lohnt es sich, beides anzubieten.

Was mich persönlich am meisten beeindruckt hat, ist die Verschiebung der Perspektive. Ich bin es seit vielen Jahren gewohnt, Code zu schreiben, der Maschinen sagt, was sie machen sollen. Bei einem Claude-Code-Plug-in hingegen schreibe ich lediglich natürlichsprachlichen Text, der einem Sprachmodell erklärt, was es tun soll. Das klingt technisch nach einem kleinen Unterschied, fühlt sich aber nach einem großen an. Die Frage ist nicht mehr „Wie implementiere ich das?“, sondern „Wie erkläre ich das so, dass es verstanden wird?“. Das ist vergleichbar mit einer Erklärung, die man Kolleginnen und Kollegen gibt.

Wer das Plug-in ausprobieren möchte, findet den Quellcode auf GitHub. Die Installation in Claude Code erfordert lediglich die beiden oben genannten Befehle. EventSourcingDB lässt sich bis 25.000 Events kostenfrei nutzen, sodass dem Experimentieren nichts im Wege steht. Wer ein eigenes Plug-in für eine andere API bauen möchte, braucht dafür nicht mehr als ein leeres Verzeichnis und die Bereitschaft, präzise zu formulieren.


(rme)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Android öffnet ein paar Server-Ports


Google wird Android-Apps erlauben, ein Dutzend well-known Ports (kleiner als 1024) zu nutzen – etwa als Server respektive Service. Das öffnet neue Einsatzmöglichkeiten für populäre Android-Geräte, insbesondere im lokalen Netzwerk. Konkret sollen mit dem nächsten Update des Google Play Systems Android-Apps bei Bedarf Dienste auf diesen neun TCP-Ports anbieten dürfen: 20 und 21 (typischerweise für FTP genutzt), 22 (SSH/SFTP), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 445 (SMB), sowie die beiden regelmäßig für vernetzte Drucker eingesetzten Ports 515 (LPD) und 631 (IPP).

Weiterlesen nach der Anzeige

Hinzu kommen drei UDP-Ports: 319/320 (typischerweise für Zeitgeber-Synchronisierung mittels PTP) und 443 (für das QUIC-basierte WWW-Protokoll HTTP/3). Das geht aus einer am Wochenende veröffentlichten Mitteilung im öffentlichen Bugtracker Androids hervor. Kein Glück haben beispielsweise Nutzer von TFTP (UDP-Port 69) oder Doom-Fans (klassisch Port 666).

Bislang sperrt Google auf seinen Android-Versionen grundsätzlich Ports kleiner 1024. Nur wenn solche Android-Implementierungen gerootet sind, kann der Administrator die sogenannten well-known Ports zugänglich machen. Das schwächt unter Umständen bestimmte IT-Sicherheitsmaßnahmen.

Ein bisschen Glasnost

Daher regen Entwickler im Android Bugtracker seit vielen Jahren an, die Einschränkung fallen zu lassen. Doch Google hat das mehrfach als „absichtliches Verhalten” eingestuft und das Gesuch abgelehnt („Won’t Fix”). Im Oktober 2021 überraschte ein Googler mit der „Erklärung”, dass „raw sockets konstante Quelle für kernel exploits” seien, weshalb die Verbesserung nicht infrage komme. Dabei hatte niemand nach raw sockets (OSI-Layer 2 oder 3) gefragt, sondern lediglich nach Zugang für unprivilegierte Apps auf Layer 4.

Auch den zumindest dritten Anlauf vor gut vier Jahren hat Google mit „Won’t Fix” abgeschmettert. Doch vorige Woche entdeckte ein womöglich deutscher Entwickler, dass Anwendungen in der Developer Preview auf Android 17 Zugriff auf die UDP-Ports 319 und 320 ergattert haben.

Daraufhin rang Google sich zu einer teilweisen Öffnung durch, auch für altere Androids. Die grundsätzliche Herangehensweise, well-known Ports zu sperren, bleibt aufrecht. So viel Orthodoxie muss offenbar sein. Immerhin wird die Nutzung der zwölf obgenannten Ports ermöglicht.

Technisch gesehen setzt Google die neue Port-Whitelist mittels eBPF (extended Berkley Packet Filter) um. Das erfolgt in jenem APEX-Modul, das in Android Mainline für Datenverbindungen samt Tethering zuständig ist. Solche Module können durch Google Play Updates erneuert werden und bedürfen keines Updates des gesamten Betriebssystems. Der Konzern könnte Zukunft also relativ einfach weitere well-known Ports zur Verfügung stellen, wenn er denn möchte.

Weiterlesen nach der Anzeige

Voraussetzungen und Vergleich

Voraussetzung für den neuen Portzugriff sind sowohl mindestens Android 13 (API-Version 33 und höher) als auch mindestens Linux-Kernel 5.15. Damit sind Anwender erst mit Systemen, die neu mit Googles Android 14 ausgeliefert wurden, auf der sicheren Seiten. Mobiltelefone, die mit Googles Android 13 neu ausgeliefert wurden, durften Kernel 5.10 oder 5.15 nutzen, sind also nicht alle mit dabei. Geräte, die mit älteren Android-Versionen auf den Markt gekommen und später auf jüngere Versionen des Betriebssystems upgegradet worden sind, können sogar mit noch älteren Kernel-Versionen laufen.

Bei den Android-Varianten Android Auto, TV und Wear könnte die Verbesserung länger auf sich warten lassen. Das gilt auch für Android Go; das ist eine für weniger leistungsstarke Handys und Mobilfunknetze optimierte Android-Variante.

Die Einschränkung der niedrigen Ports ist auch bei anderen Linux-Systemen üblich. Allerdings ist es dort Administratoren in der Regel ein Leichtes, bei Bedarf Anwendungen den Zugriff zu gestatten. Für MacOS galt das nicht, doch können nicht-privilegierte Anwendungen seit Version 10.14 über die Wildcard-Adresse 0.0.0.0 auch an well-known Ports andocken. Den nicht auf Linux basierenden Betriebssystemen iOS und Windows ist die strikte Portnummern-basierte Blockade fremd.


(ds)



Source link

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

Beliebt