Erik Wilde hat jahrelange Erfahrung im API-Bereich. Als Botschafter bei der OpenAPI-Initiative setzt er sich für den Einsatz offener Standards und Best Practices in API-Design und -Management ein. Auf YouTube betreibt er den Channel Getting APIs to Work, der sich an IT-Experten, Entwicklerinnen und Produktmanager richtet. Außerdem hat Wilde zahlreiche Artikel und Bücher geschrieben, und er spricht regelmäßig auf Fachkonferenzen.

iX: Schnittstellen sind ein absolutes Grundkonzept der Softwarearchitektur; man entwirft, implementiert und überarbeitet sie ständig für die Anwendungsprogrammierung. Wann beginnt man, eine Schnittstelle als API zu bezeichnen? Die Semantik dieses Wortes geht über die reine Abkürzung hinaus.

Erik Wilde: Man bezeichnet eine Schnittstelle als API, sobald sie über ihren unmittelbaren Implementierungskontext hinaus von anderen genutzt werden soll. Eine Schnittstelle ist nur eine technische Grenze, eine API hingegen ein veröffentlichter Vertrag. Das bedeutet, dass sie absichtlich offengelegt, dokumentiert und stabil genug ist, damit andere – innerhalb oder außerhalb des Entwicklerteams oder Systems – sich darauf verlassen können. Es ist vor allem der Aspekt der Absicht und des breiteren Publikums, der eine API auszeichnet.

iX: Sind die Ansätze, die eine API für Menschen nützlich und zugänglich machen, nicht dieselben wie diejenigen, die sie für KI, also LLM-basierte Automatisierung, zugänglich machen?

Wilde: Sowohl Menschen als auch Maschinen benötigen zugängliche APIs, jedoch auf unterschiedliche Weise. Für Menschen funktioniert die Dokumentation am besten, wenn APIs einheitliche Muster aufweisen, da das nicht nur das Verständnis erleichtert, sondern auch die Wiederverwendung von Tools und Verfahren für verschiedene APIs ermöglicht. Menschen können auch einen breiteren Kontext heranziehen, ohne verwirrt zu werden. Maschinen hingegen benötigen eine klare, in sich geschlossene Beschreibung jeder API. Selbst wenn die Kontextfenster größer werden, ist mehr Kontext nicht immer hilfreich – KI hat oft Schwierigkeiten, größere Kontexte effektiv zu nutzen.

Menschen schätzen APIs, die offen, wiederverwendbar und flexibel anpassbar sind, während Maschinen mehr von einer geführten Abstraktionsebene profitieren, die den Schwerpunkt darauf legt, was erreicht werden kann und wie dies zu tun ist, anstatt jede mögliche Operation offenzulegen.

iX: Sie haben sich in der Vergangenheit in Ihrem YouTube-Channel „Getting APIs to Work“ mit dem ökologischen Fußabdruck von APIs befasst. Wenn man über Softwareeffizienz und CO₂-Bewusstsein nachdenkt, passt das dann gut zu dem, was derzeit als Agentic AI beworben wird?

Wilde: Der ökologische Fußabdruck von Agentic AI ist erheblich, da die explorative Nutzung durch Agenten oft zu mehr Orchestrierung, mehr Rechenzyklen und einem höheren Energieverbrauch führt. Das scheint im Widerspruch zu den Bestrebungen nach Effizienz und CO₂-Bewusstsein bei Software und APIs zu stehen.

Der Weg nach vorne besteht darin, sie als komplementär zu betrachten: Agenten können kreative Lösungen erforschen und neue Vorgehensweisen aufdecken, aber sobald ein vielversprechender Ansatz gefunden ist, sollte er in einen deterministischen, wiederholbaren Workflow kodifiziert werden, der energieeffizient, skalierbar und überprüfbar ist. Das bringt die Vorteile der Kreativität der KI mit der Notwendigkeit eines nachhaltigen und konformen Betriebs in Einklang, wobei so viel KI wie nötig, aber so wenig wie möglich eingesetzt wird.

Durch das Entwickeln von Architekturen, die einen reibungslosen und bewussten Übergang vom Experimentieren zur effizienten Ausführung ermöglichen, können wir sowohl die Unsicherheit hinsichtlich der Unvorhersehbarkeit der KI als auch die Notwendigkeit angehen, ihren erheblichen Energieverbrauch zu kontrollieren.

iX: In welcher Beziehung steht MCP zu OpenAPI? Verfolgen beide nicht dasselbe Ziel: die Standardisierung der Beschreibung von APIs und deren einfache Zugänglichkeit? Oder ähnelt es eher JSON:API, also der Standardisierung der APIs selbst?

Wilde: Bei MCP, OpenAPI und JSON:API geht es darum, Funktionen verfügbar zu machen, aber sie richten sich an unterschiedliche Nutzer. MCP wurde speziell für LLMs entwickelt und stellt ihnen Tools und Ressourcen zur Verfügung, die auf ihre Arbeitsweise zugeschnitten sind. OpenAPI hingegen richtet sich an Entwickler, die HTTP-APIs nutzen möchten, und konzentriert sich hauptsächlich darauf, Endpunkte zu strukturieren und diesen Schemata hinzuzufügen.

JSON:API fügt eine weitere Ebene hinzu, indem es standardisiert, wie die Schemata strukturiert sind und welche gemeinsamen Konzepte eine API offenlegen sollte, sodass Entwickler von bereits bekannten Konventionen profitieren und Tools wiederverwenden können, die diese unterstützen.

Es ist zwar möglich, MCP-Server automatisch aus OpenAPI zu generieren, aber das führt in der Regel nicht zu den besten Ergebnissen: Bei komplexeren APIs reicht eine Liste von Endpunkten nicht aus, da LLMs das implizite Verständnis fehlt, das Menschen beim Schreiben von Code mitbringen. Das ist der grundlegende Unterschied: OpenAPI und JSON:API gehen davon aus, dass ein menschlicher Developer die Lücken füllen kann, während MCP eine ausreichend aufgabenorientierte Struktur bereitstellen muss, damit ein LLM ohne diese menschliche Intelligenz erfolgreich sein kann.

iX: Machen LLMs bestimmte Ansätze zur Automatisierung überflüssig? Oder sind sie nur ein weiterer Anwendungsfall? Aufgrund der Nicht-Determiniertheit können sie eine zuverlässige Systemintegration vermutlich nicht wirklich ersetzen.

Wilde: Bei der Automatisierung geht es in der Regel um Zuverlässigkeit, Wiederholbarkeit und Effizienz, was LLMs nicht bieten. Sie sind nicht deterministisch, nicht zuverlässig reproduzierbar und nicht besonders effizient. Was sie jedoch bieten, ist eine neue Art von Kreativität: die Fähigkeit, Lücken zu schließen, Lösungen auszuprobieren und chaotischere Teile der Automatisierung zu bewältigen, die mit traditionellen Ansätzen nicht möglich sind.

Am besten betrachtet man sie als ein weiteres Werkzeug im Werkzeugkasten – eines, das wir selektiv einsetzen können, zum Erkunden oder für bestimmte Teile eines Prozesses, aber nicht für die Teile, die strenge Garantien erfordern. Architekturen, die LLM-gesteuerte Erkundung mit kodifizierten, deterministischen Workflows kombinieren, können das Beste aus beiden Welten vereinen: KI, wo Kreativität einen Mehrwert schafft, und traditionelle Automatisierung, wo Zuverlässigkeit unerlässlich ist.

Das Interview führte Richard Wallintin von WPS – Workplace Solutions.

(rme)

Mit smolBSD, einer liebevollen Verniedlichung von smallBSD, hat der spanische NetBSD-Entwickler Emile „iMil“ Heitor eine Umgebung geschaffen, um winzige NetBSD-Installationen zu erzeugen. Das schlanke Design soll die Grundlage für ein stabiles System mit möglichst geringem Ressourcenbedarf sein, das auf Sicherheit und Performance optimiert ist. Damit ist es für den Einsatz in eingebetteten Systemen, Containern, virtuellen Maschinen oder auf verschiedenen auch betagten Architekturen geeignet – ausdrücklich auch mit einem 32-Bit-Kernel für die x86-Plattform.

Mini-Systeme, Appliances und vor allem MicroVMs

Vor allem ist das minimalistische smolBSD aber dafür gedacht, als MicroVM (Micro Virtual Machine) in kurzlebigen, isolierten und sicheren Ausführungsumgebungen zu laufen. MicroVMs stellen beispielsweise QEMU, Cloud Hypervisor und Amazon mit Firecracker bereit. Auf der smolBSD-Projektseite werden QEMU und Firecracker als explizit funktionierende Plattformen genannt.

Details zu seiner Motivation, smolBSD zu entwickeln, und Informationen zum internen Aufbau präsentierte Heitor auf der BSDcon 2024 an der Universität in Ottawa in seinem Vortrag Making NetBSD a fast(er) booting microvm. Sein Projekt zieht bereits weitere Entwickler wie Leah Neukirchen an, der mit nitro ein kleines, flexibles und vor allem portables init-Framework samt Prozess-Supervisor (PID 1) geschaffen hat, das auch unter smolBSD läuft.

Erstaunlich einfach, schnell und problemlos

Um einen Blick auf smolBSD-MicroVMs zu werfen, benötigt man ein System mit Intel VT-x oder AMD-V, auf dem NetBSD, GNU/Linux oder macOS laufen. Ein Test mit dem systemd-losen Devuan GNU/Linux verlief problemlos, nachdem ein paar Pakete (qemu-system-x86, curl, git, bmake, uuid-runtime, bsdtar) installiert wurden. In der per git geklonten Kopie von smolBSD können Funktion und Konfiguration der MicroVMs im etc- und dem service-Verzeichnis angepasst werden. Vorgefertigte Beispiele wie ein simpler SSH-Zugang, ein SSH-Bouncer und ein Webserver sind im etc-Verzeichnis vorhanden. Das Image der MicroVM wird anschließend über bmake erzeugt und kann dann verteilt oder direkt über das startnb.sh-Skript gestartet werden.

Bei Microservices zählen Millisekunden

Im Zeitalter von Cloud-Architekturen, Serverless-Computing und Microservices werden immer fetter werdende Betriebssysteme mehr und mehr unattraktiv. Gewünscht sind extrem schlanke Systeme, die nur das enthalten, was wirklich gebraucht wird, und idealerweise quasi in Echtzeit starten. Ein Beispiel ist Amazons Firecracker, ein leichtgewichtiger Virtual Machine Monitor (VMM) via KVM, der speziell für das schnelle und sichere Starten isolierter MicroVMs in Cloud- und Serverless-Umgebungen entwickelt wurde. AWS Lambda (FaaS) und AWS Fargate (CaaS) führen Funktionen beziehungsweise Dienste oder Container ohne eigene Server-Basis aus. Auch QEMU bietet seit einiger Zeit „microvm“ als „machine type“ an.

Normalerweise werkelt in den Firecracker-MicroVMs Linux, in den letzten Jahren hat jedoch der FreeBSD-Entwickler Colin Percival FreeBSD für die Ausführung unter Firecracker tauglich gemacht. Das Projekt gilt noch als experimentell, aber die Startzeiten in seinen Tests von 25ms oder sogar unter 20ms im Vergleich zu Linux mit 75ms oder mehr zeigen, dass einiges an Potenzial in BSD-basierten MicroVMs steckt – und das nicht nur, weil AWS die Firecracker-Kosten in Millisekunden abrechnet. Laut dem Entwickler von smolBSD soll sein NetBSD-MicroVM-Kernel unter QEMU – also auf einer nicht wirklich vergleichbaren Umgebung – in 10 bis 14ms starten. Hier müssen konkrete Praxistests die echte Performance der drei Lösungen zeigen.

Fazit

Sicherlich ist es ein sicherheitstechnischer Vorteil, wenn MicroVMs nicht nur auf eine Linux-Monokultur setzen, sondern auch in Richtung FreeBSD und bald vielleicht NetBSD diversifiziert werden können. Mit smolBSD entsteht eine zusätzliche, sympathische Alternative.

(fo)

Auf Reddit kursierte unlängst ein Bild, das fünf Paletten mit originalverpackten MSI-Grafikkarten vom Typ GeForce RTX 5090 zeigt. Die Krux: Es soll in China entstanden sein, wo Nvidias GeForce RTX 5090 aufgrund von Exporteinschränkungen gar nicht verfügbar sein dürfte. Grau- und Schwarzimporte sind üblich, allerdings überraschte die Menge an neuen Grafikkarten in offenbar einer einzigen Lieferung.

MSI veranlasste der Reddit-Beitrag zu einer Mitteilung: „MSI hat jüngste Online-Gerüchte zur Kenntnis genommen, wonach die GeForce RTX 5090 in China im Umlauf sei und dadurch Marktverwirrung entstehe. MSI stellt klar, dass die GeForce RTX 5090 weder offiziell verkauft noch über autorisierte Kanäle in China vertrieben wird. Alle lokal entdeckten Einheiten stammen nicht aus von MSI autorisierten Vertriebskanälen und sind über nicht genehmigte Parallelimporte in den Markt gelangt, die nicht im Einklang mit der offiziellen Vertriebspolitik von MSI stehen.“

Exportnetzwerke in Asien

Eine Untersuchung der New York Times untermauert derweil, dass chinesische Firmen trotz aller Einschränkungen offenbar im großen Stil an High-End-Hardware gelangen können. Im Fokus des Berichts steht die Firma Megaspeed, die aktuelle KI-Beschleunigerchips von Nvidia im Wert von zwei Milliarden US-Dollar gekauft hat.

Megaspeed ist offiziell in Singapur ansässig, hat aber chinesische Wurzeln: Der chinesische Cloud-Gaming-Anbieter 7Road gliederte die Firma 2023 aus. Die New York Times hat ein mutmaßliches Netzwerk aus Briefkastenfirmen mit weitgehend leeren Büros aufgedeckt und stellt über Importdaten Verbindungen zu weiteren chinesischen Unternehmen her.

Demnach soll Megaspeed einen Großteil seiner Chips von Aivres gekauft haben, eine US-Tochter der chinesischen Firma Inspur, die auf der US-Entity-Liste steht und angeblich Supercomputer für das chinesische Militär baut. Inspur darf daher offiziell keine Chips von westlichen Unternehmen kaufen, allerdings gilt die Einschränkung nicht für westliche Tochterfirmen. Nvidia selbst soll weitere Lieferungen für Megaspeed vorbereitet haben, bevor Megaspeed überraschend die Zahlungen einstellte.

Ein weiteres Schlupfloch: Megaspeed soll einen Teil der Chips nach Malaysia und Indonesien verschickt haben, wo sie in Rechenzentren angblich chinesischen Kunden per Cloud-Zugriff zur Verfügung gestellt werden. Es gibt aber auch Vorwürfe, dass Megaspeed KI-Beschleuniger direkt nach China weiterverschickt haben soll.

Laut mehreren Aussagen haben US-Behörden bereits eine Untersuchung gegen Megaspeed eingeleitet, sind bisher aber noch zu keinem Ergebnis gekommen. Nvidia beteuert, von keinen illegalen Aktivitäten zu wissen.

Nvidia riesigen Umsatz in Singapur

Singapur steht schon seit 2024 immer wieder im Fokus möglicher Chipexporte nach China. Nvidia verbucht über ein Fünftel seines diesjährigen Umsatzes auf Firmen in Singapur, weil die Kunden dort ihre Rechnungen zentralisieren würden. Allein im ersten Halbjahr entspricht das fast 20 Milliarden US-Dollar.

„Über 99 Prozent der kontrollierten Rechenzentrenumsätze, die Singapur in Rechnung gestellt wurden, entfielen auf Aufträge von Kunden mit Sitz in den USA“, beteuert Nvidia im eigenen Geschäftsbericht.

Die Fälle zeigen, wie schwierig es für die USA ist, Exportkontrollen bei hoch gefragten Technologien durchzusetzen, wenn hohe Gewinne locken und Lieferketten mit international verzweigten Firmengeflechten verschleiert werden.

(mma)