Cloudflare hat ein neues, einheitliches Kommandozeilen-Tool vorgestellt, das alle Produkte und APIs des Anbieters abdecken soll. cf befindet sich aktuell in einer Preview und soll langfristig die bisherige Fragmentierung auflösen: Statt je nach Produkt zwischen Dashboard, Wrangler-CLI, Terraform und REST-API zu wechseln, sollen Entwickler künftig alle Dienste über ein einziges Werkzeug steuern können. Gleichzeitig richtet Cloudflare das Tool auf die Nutzung durch KI-Agenten aus. Ebenfalls neu ist der Local Explorer, der erstmals direkten Einblick in lokal simulierte Cloudflare-Ressourcen bietet.

In Cloudflares Portfolio befinden sich aktuell mehr als 100 Produkte mit rund 3.000 API-Operationen. Dazu gehören die serverlose Laufzeitumgebung Workers, die Datenbank D1, der Objektspeicher R2, der Key-Value-Store KV und Durable Objects für zustandsbehaftete Anwendungen. Bislang verwalten Entwickler diese Dienste über verschiedene Werkzeuge: die Wrangler-CLI für Workers-Deployment, Miniflare für die lokale Emulation der Laufzeitumgebung, das Web-Dashboard und Terraform. Keines dieser Tools deckt alle Produkte ab.

Genau das soll cf ändern. Es erweitert Wrangler und bildet perspektivisch die gesamte API-Oberfläche ab. Entwickler können die Preview bereits per npx cf ausprobieren oder global über npm installieren. Cloudflare plant, dass sich über das neue Tool alle Dienste nach dem Infrastructure-as-Code-Prinzip konfigurieren lassen – mit einheitlicher Syntax. Ein Beispiel wäre cf kv get statt produktabhängig variierender Befehle.

TypeScript-Schema als zentrale Quelle

Unter der Haube steckt ein neues, TypeScript-basiertes Schema, das als zentrale Quelle für alle Schnittstellen dient. OpenAPI beschreibt nur REST-Endpunkte; das neue Schema erfasst darüber hinaus CLI-Kommandos, Konfigurationsdateien, Bindings sowie lokale Entwicklung und Tests. Daraus generiert Cloudflare automatisch SDKs, Terraform-Provider, Dokumentation und CLI-Befehle. Verbindliche Regeln auf Schema-Ebene erzwingen Konsistenz: Befehle heißen immer get, nie info; Flags wie --json stehen einheitlich zur Verfügung.

Diese Konsistenz zielt vor allem auf KI-Agenten, die Cloudflare inzwischen als „primäre Kunden“ der APIs betrachtet. Agenten sind auf vorhersagbare Schnittstellen angewiesen – weicht die Syntax eines Befehls von der erwarteten Konvention ab, rufen sie nicht existierende Kommandos auf. Ebenso wichtig: Die CLI signalisiert künftig klar, ob ein Befehl lokale oder entfernte Ressourcen betrifft. Bisher konnte es passieren, dass ein Agent eine lokale Datenbank beschrieb, während der Entwickler mit Remote-Bindings arbeitete.

Local Explorer für lokale Ressourcen

Der ebenfalls vorgestellte Local Explorer ermöglicht die Inspektion und Bearbeitung lokal simulierter Cloudflare-Ressourcen. Das Werkzeug integriert sich in Wrangler und das Cloudflare-Vite-Plugin und zeigt lokal simulierte Ressourcen wie KV, R2, D1, Durable Objects und Workflows an. Bisher mussten Entwickler dafür das Zustandsverzeichnis .wrangler/state durchsuchen oder auf Drittanbieter-Tools zurückgreifen. Nun lassen sich Datenbankinhalte direkt prüfen, Testdaten einfügen oder Tabellen zurücksetzen.

Technisch stellt der Local Explorer eine lokale Spiegelung der Cloudflare-API unter /cdn-cgi/explorer/api bereit. Diese verhält sich wie die produktive API, arbeitet aber ausschließlich mit lokalen Daten. Dadurch funktionieren dieselben CLI-Befehle lokal wie remote – ein Flag wie --local lenkt die Anfrage lediglich an den lokalen Endpunkt um. Ein D1-Query adressiert dann die lokale SQLite-Instanz statt der gehosteten Datenbank, ohne dass sich die Semantik ändert. Agenten können den lokalen API-Endpunkt direkt ansprechen und finden dort eine OpenAPI-Spezifikation vor.

Die Ankündigungen fallen in Cloudflares Agents Week, in der das Unternehmen seine Plattform stärker auf KI-Agenten ausrichtet. Weitere Neuerungen umfassen unter anderem Durable Object Facets für isolierte Datenbankinstanzen in dynamisch erzeugten Anwendungen, persistente Sandbox-Umgebungen für Agenten (jetzt allgemein verfügbar) sowie eine identitätsbasierte Zugriffskontrolle für ausgehende Verbindungen aus Sandboxes.

Die neue CLI unterstützt derzeit nur einen Teil der Cloudflare-Produkte. Die vollständige API-Abdeckung und die Integration bestehender Wrangler-Funktionen plant Cloudflare für die kommenden Monate. Das Unternehmen ruft Entwickler auf, über den Cloudflare-Developers-Discord Feedback zur weiteren Ausgestaltung zu geben.

(fo)

In der Cloud-Native-Szene erhalten Internal Developer Platforms (IDPs) viel Aufmerksamkeit. In ihrem Vortrag auf dem Cloud-Native-Festival CloudLand 2025 ordnen Alexander Hoeft und Artem Lajko ein, was hinter dem Konzept steckt, wo die Abgrenzung zu klassischen DevOps-Ansätzen liegt – und warum viele Organisationen noch nicht reif für den Aufbau einer solchen Plattform sind.

Das Grundprinzip einer IDP besteht darin, Entwicklerteams eine zentrale Plattform bereitzustellen, über die sie Infrastruktur und Services im Self-Service nutzen können. Statt sich selbst um Provisionierung, Konfiguration und Betrieb kümmern zu müssen, greifen Entwickler auf vorgefertigte, standardisierte Bausteine zurück. Das soll die kognitive Last senken und die Produktivität steigern.

Hoeft und Lajko betonen dabei einen wesentlichen Punkt, der in der Diskussion häufig untergeht: Die Rolle eines Platform Engineers unterscheidet sich grundlegend von der eines DevOps Engineers. Während DevOps Engineers typischerweise direkt in Produktteams arbeiten und dort Entwicklungs- und Betriebsaufgaben vereinen, agieren Platform Engineers als Dienstleister für die gesamte Organisation. Sie bauen und pflegen die Plattform, die andere Teams „konsumieren“ – behandeln deren Bedürfnisse also ähnlich wie ein Produktteam seine Endnutzer.

Wer allerdings glaubt, mit dem Aufbau einer IDP sofort loslegen zu können, dem erteilen die Sprecher eine klare Absage. Organisationen sollten zunächst ein belastbares Fundament an Automatisierung geschaffen haben, bevor sie eine Plattform darüber errichten. Konkret empfehlen Hoeft und Lajko, dass grundlegende Prozesse wie Infrastructure as Code, CI/CD-Pipelines und automatisierte Tests bereits etabliert und ausgereift sein müssen. Ohne diesen Reifegrad laufe man Gefahr, Komplexität nicht zu reduzieren, sondern lediglich auf eine neue Ebene zu verlagern.

Backstage als IDP-Komponente: Kein Selbstläufer

Ein konkretes Werkzeug, das in der IDP-Diskussion regelmäßig auftaucht, ist das von Spotify entwickelte, heute von der CNCF betreute Open-Source-Projekt Backstage. Es dient als Developer-Portal und kann als zentrale Oberfläche für eine IDP fungieren. Hoeft und Lajko warnen jedoch vor typischen Fallstricken beim Einsatz: Backstage sei keine schlüsselfertige Lösung, sondern ein Framework, das erheblichen Anpassungs- und Pflegeaufwand erfordere. Wer es einführe, ohne genügend Ressourcen für die kontinuierliche Weiterentwicklung einzuplanen, ende schnell mit einer halbfertigen Plattform, die von den Entwicklerteams nicht angenommen werde. Zudem bestehe die Gefahr, Backstage als reinen Service-Katalog zu betreiben, ohne die dahinterliegenden Automatisierungsschichten tatsächlich aufzubauen.

Trend oder nachhaltige Entwicklung?

Die zentrale Frage des Vortrags – ob IDPs nur ein Trend sind – beantworten die Sprecher differenziert. Das zugrundeliegende Konzept, Entwicklern Infrastruktur als Produkt anzubieten, sei keineswegs neu und habe sich in großen Technologieunternehmen bereits bewährt. Allerdings müsse jede Organisation ihren eigenen Reifegrad realistisch einschätzen. Eine IDP ist demnach kein Projekt, das man nebenbei aufsetzt, sondern eine strategische Entscheidung, die personelle Ressourcen, Organisationsstruktur und technische Voraussetzungen gleichermaßen betrifft.

Über die Speaker

Alexander Hoeft und Artem Lajko sind für das IT-Beratungsunternehmen iits-consulting tätig. Hoeft arbeitet dort in der Rolle eines Senior Platform Engineer und ist darüber hinaus als Blogger und Sprecher auf Konferenzen aktiv. Lajko ist Head of Platform Engineering bei iits und außerdem Platform Engineering Ambassador und Kubestronaut. Auch er ist Blogger, Speaker und zudem Buchautor („Implementing GitOps with Kubernetes“).

(map)

Im Tiobe-Index für April 2026 ist Rust von seinem Höchststand von Platz 13 Anfang des Jahres auf Rang 16 zurückgefallen. Die Herausgeber des monatlichen Index sehen das als Anzeichen dafür, dass sich der seit 2020 bestehende Aufstieg der Sprache insgesamt verlangsamt.

Python führt das Ranking mit 20,97 Prozent an Suchtreffern weiterhin an, gefolgt von C (12,34 Prozent), C++ (8,03 Prozent), Java (7,79 Prozent) und C# (5,98 Prozent) – diese Sprache hatte Tiobe erst im Januar zur Programmiersprache des Jahres 2025 gekürt.

Rust erreicht im aktuellen Ranking einen Anteil von 1,09 Prozent. Tiobe-Chef Paul Jansen sieht die Ursache für den Abstieg vor allem in der hohen Einstiegshürde: „Rust bleibt für Nicht-Experten schwierig zu erlernen“. Konzepte wie Ownership und Borrowing erfordern für Umsteiger ein grundlegendes Umdenken.

C zeigt eine gegenläufige Tendenz, da die Sprache mit einem Plus von 2,39 Prozentpunkten deutlich zulegen konnte. Das ist verwunderlich, denn C gilt als unsichere Variante für hardwarenahe Programmierung im Vergleich zu Rust, und immer mehr Entwicklerinnen und Entwickler wenden sich davon ab, gerade auch in den großen Organisationen wie Google, Microsoft oder dem Linux-Kernel-Team.

Rust als typsichere Programmiersprache bildet auch im Umgang mit KI einen Vorteil gegenüber vielen anderen Sprachen, da sie zu mehr Eindeutigkeit und weniger Fehlern führt. Der Verlauf der letzten Monate lässt sich auch als normale Schwankung interpretieren.

Die Methodik des Tiobe-Index gilt in der Branche als zweifelhaft, denn sie misst nicht die tatsächliche Verwendung von Sprachen durch Entwickler, sondern deren Interesse daran – gemessen an Suchtreffern im Web. Die Quote steht für den Anteil von Suchtreffern einer Programmiersprache gegenüber allen Programmiersprachen. Tiobe wertet dazu die Ergebnisse von 25 Suchmaschinen aus, darunter Google, Wikipedia oder Amazon.

Der Herausgeber muss künftig zeigen, wie tragfähig diese Methode im KI-Zeitalter noch ist, in dem die meisten Programmiererinnen und Programmierer eher ihren Coding-Assistenten befragen als Google.

(who)