Airbyte hat Version 2.0 seiner freien Datenintegrationsplattform veröffentlicht und verspricht damit eine deutliche Beschleunigung der Datenverarbeitung. Nach Angaben der Entwickler synchronisiert die neue Version Daten im Durchschnitt vier- bis sechsmal schneller als bisher, während sie gleichzeitig den Ressourcenverbrauch optimiert. Die Funktion „Faster Sync Speed“ ist nun allgemein verfügbar und soll ELT-Prozesse (Extract, Load, Transform) deutlich effizienter gestalten.

Die wichtigsten neuen Features

Gut ein Jahr nach der Veröffentlichung von Airbyte 1.0 überarbeitet das neue Major Release die Architektur der Open-Source Plattform. Neben der Performance-Steigerung führt Version 2.0 zwei zentrale neue Funktionen ein: Data Activation und Enterprise Flex. Data Activation ermöglicht es Unternehmen, aufbereitete Daten aus ihrem Data Warehouse direkt in operative Systeme wie CRM-Plattformen, Marketing-Tools oder Support-Systeme zurückzuspielen. Damit lassen sich Business-Entscheidungen nicht mehr nur auf Basis von Dashboards und Reports treffen, sondern direkt in den Arbeitstools umsetzen, die Teams täglich nutzen.

Enterprise Flex richtet sich speziell an Unternehmen mit strengen Compliance- und Data-Sovereignty-Anforderungen. Die hybride Architektur kombiniert eine vollständig verwaltete Cloud-Control-Plane mit separaten Data Planes, die Nutzer in ihrer eigenen Infrastruktur betreiben können. Das ist besonders für Organisationen relevant, die aus regulatorischen Gründen – etwa Datenschutz mit der DSGVO – die vollständige Kontrolle über Datenbewegungen behalten müssen, und trotzdem Managed Services einsetzen wollen. Bestehende Airbyte-Cloud-Kunden können auf Enterprise Flex umsteigen.

Der Connector Builder, mit dem Entwickler eigene Konnektoren für APIs und Datenquellen erstellen können, wurde grundlegend überarbeitet. Die Benutzeroberfläche orientiert sich nun stärker an der zugrundeliegenden YAML-Spezifikation, was den Wechsel zwischen UI- und YAML-Modus intuitiver gestalten soll. Nahezu alle Funktionen, die bisher nur im YAML-Modus verfügbar waren, lassen sich nun über die grafische Oberfläche nutzen. Bestehende Custom Connectors migrieren automatisch zur neuen Oberfläche, ohne dass Entwickler eingreifen müssen.

OAuth 2.0 und flexible Stream-Konfiguration

Eine wesentliche Neuerung im Connector Builder ist die vollständige Unterstützung von OAuth-2.0-Flows, einschließlich asynchroner Streams. Jeder Stream lässt sich jetzt mit einer eigenen API-Endpoint-URL und einer individuellen Authentifizierungsmethode konfigurieren – die bisherige globale Konfiguration für Base-URL und Authentifizierung entfällt. Das neue Feld API Endpoint URL ersetzt die vorherigen separaten Felder für URL-Pfad und API-Base-URL. Zudem hat Airbyte die Panels für Parent Streams und Parameterized Requests im neuen Partition Router zusammengeführt. Ein zusätzliches Advanced-Panel macht Funktionen wie Dateitransfers zugänglich, die zuvor nur im YAML-Modus nutzbar waren.

Helm Chart V1 läuft aus – Migration erforderlich

Für Administratoren selbst gehosteter Airbyte-Installationen bringt Version 2.0 eine wichtige Änderung: Es ist die letzte Version, die Helm Chart V1 unterstützt. Ab Version 2.1 wird also Helm Chart V2 zur Pflicht. Neue Deployments sollten daher direkt auf Helm Chart V2 setzen; bestehende Installationen sollten zeitnah migrieren, um künftige Updates nicht zu blockieren. Die Airbyte-Dokumentation bietet separate Migrations-Guides für Core und Self-Managed Enterprise. Wer Airbyte mit dem Tool abctl einrichtet, muss vor dem Upgrade auf Version 2.0 zunächst auf abctl Version 0.30.2 aktualisieren.

Überarbeitete Organisations-Verwaltung

Die Benutzeroberfläche für Organisationen und Workspaces haben die Entwickler ebenfalls neu strukturiert. Die Navigationsleiste trennt nun klar zwischen Organisations- und Workspace-Ebene, die allgemeinen Einstellungen haben sie in separate Bereiche für Organisation und Workspace aufgeteilt. Nutzer-Einstellungen und Anwendungs-Tokens finden sich ab sofort unter dem Benutzernamen im Menü. Organisationen erhalten eine neue Startseite, die alle Workspaces sowie laufende, erfolgreiche und fehlgeschlagene Syncs übergreifend darstellt – eine Art Dashboard-Ansicht für alle zugänglichen Workspaces. Darüber hinaus liefert Version 2.0 mit dem Helm Chart nun standardmäßig Ingress-Konfigurationen aus, was die Einrichtung neuer Deployments vereinfachen soll.

Airbyte 2.0 steht ab sofort sowohl als selbst gehostete Open-Source-Version als auch über Airbyte Cloud zur Verfügung. Die vollständigen Release Notes mit allen technischen Details finden sich im GitHub-Repository des Projekts.

(fo)

Oracle hat auf seiner Hausmesse Oracle AI World in Las Vegas mehrere Neuerungen für Unternehmen vorgestellt. Mit der neuen AI Data Platform und einem AI Agent Marketplace für Fusion Cloud Applications will der Konzern die Nutzung von KI im Unternehmensumfeld vereinfachen und standardisieren.

Die Oracle AI Data Platform ist laut Hersteller für den Aufbau und Betrieb von KI-Anwendungen konzipiert. Sie kombiniert automatisierte Datenaufnahme, semantische Optimierung und Vektorindizierung mit integrierten generativen KI-Werkzeugen. So sollen Unternehmen Rohdaten schneller in verwertbare Erkenntnisse überführen und eigene KI-Agenten in bestehende Abläufe einbinden können.

Zum Einsatz kommen mehrere Oracle-Komponenten, darunter die Cloud-Infrastruktur (OCI), die Autonomous AI Database und der Generative AI Service. Die Plattform unterstützt offene Lakehouse-Formate wie Delta Lake und Iceberg und bietet Zero-ETL- und Zero-Copy-Zugriff auf operative Daten aus Finanz-, HR- oder Supply-Chain-Systemen. Ein IT-Servicekatalog soll zudem eine einheitliche Governance über alle Daten- und KI-Assets ermöglichen. Als zentrale Schaltstelle dient der sogenannte Agent Hub: Er wertet Anfragen aus, leitet sie an die entsprechenden Agenten weiter und bündelt die Ergebnisse.

Erweiterung der Fusion Cloud Applications

Zusätzlich erweitert Oracle seine Fusion Cloud Applications um vorgefertigte Agenten, darunter welche für Finanzplanung, Rechnungsbearbeitung und HR-Talentmanagement. Sollten die Agenten für das benötigte Szenario nicht reichen, führt der Hersteller mit dem AI Agent Marketplace eine weitere Bezugsquelle ein. Partnerunternehmen wie Accenture oder Infosys, aber auch Softwareanbieter wie Box oder Stripe, bieten dort spezialisierte KI-Agenten als geprüfte und einsatzbereite Vorlagen an. Alle Agenten können direkt in bestehenden Arbeitsabläufen arbeiten, Daten in Echtzeit analysieren, Empfehlungen liefern und wiederkehrende Aufgaben automatisieren.

Schließlich wurde auch das AI Agent Studio erweitert. Es unterstützt nun mehrere große Sprachmodelle, darunter OpenAI, Anthropic, Cohere, Google, Meta und xAI. Neue Funktionen sollen den gesamten Lebenszyklus von Agenten abdecken, von der Erstellung über das Testen bis hin zur Beobachtung und Betrieb. Dazu gehören Monitoring-Dashboards, Prompt-Management, Multimodale-RAG und ein Credential-Store zur Speicherung von API-Schlüsseln und Token.

Mehr Informationen zu den Ankündigungen finden sich hier:

(fo)

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)