Connect with us

Entwicklung & Code

Platform Engineering vs. DevOps: Was steckt hinter Internal Developer Platforms?


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.

Weiterlesen nach der Anzeige

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.

Lesen Sie auch

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.

Weiterlesen nach der Anzeige

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.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier eine Vimeo-Video (Vimeo LLC) geladen.

CloudLand 2025: Internal Developer Platform: Was steckt dahinter und ist es nur ein Trend? (Alexander Hoeft, Artem Lajko)

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“).


Alexander Hoeft

Alexander Hoeft

Alexander Hoeft


Artem Lajko

Artem Lajko

Artem Lajko


(map)



Source link

Entwicklung & Code

Mozilla: Offene KI kommt an – das Geld aber nicht


Open-Source-KI hat nach Einschätzung von Mozilla einen Wendepunkt erreicht. Der Browserhersteller sieht offene Sprachmodelle nicht länger als technologisch deutlich unterlegen gegenüber proprietären Angeboten wie ChatGPT oder Claude. Laut dem ersten „State of Open Source AI“-Report beträgt der Leistungsabstand zu den führenden geschlossenen Modellen auf Basis der LMSYS Chatbot Arena nur noch rund 3,3 Prozentpunkte. Gleichzeitig seien die Inferenzkosten innerhalb von drei Jahren von rund 20 US-Dollar auf etwa 40 Cent pro Million Token gesunken.

Weiterlesen nach der Anzeige

Trotz dieser Entwicklung profitiert das Open-Source-Ökosystem wirtschaftlich bislang kaum. Mozilla zufolge kommen offene Modelle inzwischen auf etwa ein Drittel der realen KI-Nutzung, erzielen aber lediglich rund vier Prozent der Umsätze. Der Report basiert auf einer eigenen Analyse sowie einer weltweiten Umfrage unter mehr als 950 Entwicklern, die Mozilla gemeinsam mit dem Marktforschungsunternehmen SlashData durchgeführt hat.

Nach den Umfragedaten setzen 79 Prozent der befragten Entwickler offene KI-Modelle ein. In produktiven Umgebungen landen sie jedoch deutlich seltener: 51 Prozent haben Open-Source-Modelle produktiv eingeführt, während der Anteil bei proprietären Modellen 63 Prozent beträgt.

Mozilla führt diese Lücke weniger auf die Qualität der Modelle als auf fehlende Infrastruktur zurück. Die Autoren sehen Defizite vor allem bei Werkzeugen für den produktiven Betrieb, Standardisierung und Enterprise-Support. Als häufigste Hürden nennen die Befragten Infrastruktur- und Rechenkosten, Sicherheits- und Compliance-Anforderungen sowie den Aufwand für Betrieb und Skalierung. Auffällig sei zudem, dass der produktive Einsatz offener Modelle mit zunehmender Unternehmensgröße kaum zunehme – anders als bei proprietären Angeboten.

Nach Auswertung verschiedener Benchmarks haben offene Modelle in Bereichen wie Programmierung, allgemeinem Wissen und dem Befolgen von Anweisungen weitgehend zu proprietären Systemen aufgeschlossen. Vorteile sehen die Autoren für geschlossene Modelle weiterhin bei komplexen Reasoning-Aufgaben, langen Kontextfenstern und agentischen Anwendungen.

Regional sieht Mozilla Ostasien und insbesondere China bei der Einführung offener KI-Modelle vorn. Dort sei Open Source inzwischen Teil der nationalen KI-Strategie. Zugleich würden immer mehr Staaten ihre KI-Infrastruktur als strategische Ressource betrachten. Nach Angaben des Berichts wurden 2024 zwölf neue nationale KI-Strategien verabschiedet. Zudem hätten inzwischen 47 Staaten Einschränkungen für die Verarbeitung kritischer Daten im Ausland eingeführt.

Weiterlesen nach der Anzeige

Als wichtigste Entwicklung beschreibt Mozilla den Bedeutungsgewinn der Software rund um die eigentlichen KI-Modelle. Entscheidend sei zunehmend die sogenannte agentische Steuerungsschicht (Agentic Harness). Sie legt fest, auf welche Daten ein KI-Agent zugreifen darf, welche Werkzeuge er verwendet, welche Informationen er dauerhaft speichert und welche Aktionen er selbstständig ausführen kann.

Nach Einschätzung von Mozilla beeinflusst diese Schicht das Verhalten eines KI-Systems teilweise stärker als der Wechsel des zugrunde liegenden Sprachmodells. Wer diese Software kontrolliere, bestimme damit maßgeblich die Fähigkeiten und Grenzen von KI-Agenten.

Der Report warnt zugleich vor Sicherheits- und Governance-Problemen. Nutzer würden Anfragen von KI-Agenten in bis zu 93 Prozent der Fälle standardmäßig bestätigen. Mozilla sieht darin Anzeichen für eine zunehmende „Consent Fatigue“: Häufige Zustimmungsabfragen führten dazu, dass Nutzer Berechtigungen kaum noch kritisch prüfen.

Mozilla fordert deshalb stärkere Investitionen in Infrastruktur, Werkzeuge und Governance für offene KI. Zu den konkreten Empfehlungen des Reports zählen unter anderem der Aufbau eines offenen Agentic Harness, die Abkehr von proprietären Metering-Systemen sowie die Schaffung portabler Berechtigungsstandards für KI-Agenten. Andernfalls bestehe die Gefahr, dass sich zwar offene Modelle technisch etablierten, skalierbare KI-Plattformen aber dauerhaft von proprietären Anbietern dominiert würden.


(fo)



Source link

Weiterlesen

Entwicklung & Code

OpenSpec: Software von KI mit Spezifikationen entwickeln


Das Tool OpenSpec für Spec-driven Development führt in Version 1.6 einen Update-Befehl ein und unterstützt Projekte mit dem Coding-Agenten Oh My Pi und dem KI-Editor TRAE.

Weiterlesen nach der Anzeige

Mit dem neuen Befehl /opsx:update können Entwicklerinnen und Entwickler eine vorhandene, mit OpenSpec erzeugte Spezifikation vor der Implementierung ändern, ohne einen komplett neuen Anlauf nehmen zu müssen.

Außerdem erzeugt OpenSpec nun Kommandos und Skills für den CLI-Agenten Oh My Pi und für die KI-Entwicklungsumgebung TRAE von ByteDance. Für Prompts hat das OpenSpec-Team zudem die Genehmigungsregeln vereinfacht, die Entwickler jetzt pauschal im Vorfeld erteilen können. Auch die Validierung von Anforderungen an ein neues Projekt arbeitet laut Release Notes nun konsistenter.

Das Kommandozeilen-Tool OpenSpec organisiert KI-Projekte mit Spec-driven Development. Das heißt, Entwickler teilen dem Tool ihre Idee mit (/opsx:explore), wobei sich auch explizit bestehender Code einbinden lässt. Das Tool arbeitet also auch brown field.

Mit /opsx:propose erzeugt OpenSpec dann die Spezifikation in verschiedenen Ordnern und Markdown-Dateien. Die Spezifikation dient als Grundlage für die eigentliche Entwicklung und führt insbesondere KI-Agenten in die richtige Richtung. Eine Ablagemöglichkeit der Specs in einem Repo ist noch beta und soll als zentrale Single Source of Truth für ein Team dienen.

Weiterlesen nach der Anzeige

Sobald die Specs fertig sind und kein /opsx:update erforderlich war, startet man die Umsetzung mit /opsx:apply. Dabei arbeitet OpenSpec mit über 25 Tools zusammen, wie Antigravity, Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, Junie, Kiro, Mistral Vibe, Qwen Code und neu eben Oh My Pi sowie TRAE. Als Modelle für OpenSpec selbst empfiehlt der Herausgeber Codex 5.5 oder Opus 4.7.

OpenSpec läuft auf Node ab Version 20.19 und ist Open Source unter MIT-Lizenz. KI-Contributions sind willkommen, solange sie geprüft und mit Modellbezeichnung im Pull Request erfolgen.


(who)



Source link

Weiterlesen

Entwicklung & Code

Wiederverwendbare Rakete: China fängt erstmals Stufe auf


Erstmals holte das Land die erste Stufe einer Trägerrakete kontrolliert zurück. Die Stufe der neuen Rakete „Langer Marsch 10B“ wurde auf einer Plattform auf See aufgefangen, wie die staatliche Nachrichtenagentur Xinhua berichtete.

Weiterlesen nach der Anzeige

Es war der erste Flug der neuen Rakete. Xinhua sprach von einem „bedeutenden Durchbruch“. Ein von der Agentur veröffentlichtes Video zeigt, wie die Raketenstufe mit laufendem Triebwerk auf die Plattform zufliegt und nahezu senkrecht in ein hohes, rechteckiges Gerüst sinkt.

Nach Angaben der Zeitung „China Daily“ wartete das Rückholschiff „Linghangzhe“ („Pfadfinder“) auf die Raketenstufe. Das Schiff verfolgte sie und passte seine Position laufend an. Spezielle Metallhaken klappten schließlich aus und griffen in die gespannten Seile der Fangvorrichtung. Die Rakete war vom Weltraumbahnhof Hainan gestartet und brachte einen Satelliten in die vorgesehene Umlaufbahn.

China sei laut der staatlichen Zeitung damit nach den USA das zweite Land, das über eine zuverlässige Technik für wiederverwendbare Raketen verfüge. Zugleich sei weltweit erstmals die erste Stufe einer mit einer solchen Seil-Fangvorrichtung geborgen worden.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Vor allem das US-Raumfahrtunternehmen SpaceX ist bei wiederverwendbaren Raketen deutlich weiter. China treibt die Entwicklung seit Jahren voran. Neben dem staatlichen Raumfahrtprogramm arbeiten auch mehrere private chinesische Unternehmen an der Technik, die es ermöglichen soll, Satelliten und andere Lasten günstiger ins All zu bringen.

Weiterlesen nach der Anzeige

Lesen Sie auch


(afl)



Source link

Weiterlesen

Beliebt