Der API-Krieg in der Virtualisierung

TIANOW, im Gespräch mit Hema Kadia, VP und Leiter von Strategie und Praxis, wie mit dem API-Krieg umzugehen ist

Wie lösen wir die Arbeitsliste von API-Spezifikationen auf, die darum Wetteifern der Industriestandard für Virtualisierung zu sein? Hema Kadia, VP & Direktor von Strategy & Practice von Prodapt, spricht mit TIA (Telecom Industry Association) über die Risiken und Belohnungen des Gewinnens des API-Kampfes und darüber, wie man in der Zwischenzeit vorgehen soll.

VIDEO TRANSKRIPTION

Clarence: Hallo zusammen, willkommen bei TIANow. Ich bin Clarence Reynolds. Es gibt eine lange Liste von Spezifikationen, die sich als Standard für die Virtualisierung anbieten, aber wird es einen einzelnen Gewinner oder eine Reihe von Schnittstellen geben? Hema Kadia ist Vizepraesident und Leiter der Strategie bei Prodapt. Sie bespricht mit uns den API-Krieg bei der Virtualisierung. Helma, danke für Ihr Kommen.

Helma: Danke für die Einladung!

Clarence: Mit Vergnügen. Helma, wie lösen wir die Arbeitsliste von Spezifikationen auf, die darum Wetteifern der Industriestandard für Virtualisierung zu sein?

Hema: Bevor wir uns dieser Frage zuwenden, können wir die APIs der Virtualisierungsbranche in drei Kategorien einteilen. Eine ist wo uns Spezifikationen fehlen; In der zweiten Kategorie gibt es einige klar definierte Standards für bestimmte Dienstleistungen. In der dritten Kategorie haben wir, wie Sie zu Recht erwähnt haben, konkurrierende Schnittstellen. Lassen Sie mich ein Beispiel für jede der Kategorien geben und dann zur Lösung kommen.

Fehlende Spezifikationen: Einige der Beispiele wären beispielsweise eine API für einen Dienst wie Bandbreitenkalender oder APIs für Geschäftsanwendungen für einen Layer-2-VPN-Dienst oder sogar eine Basiskonfiguration für das MPLS-Netzwerk und Medienbereitstellungsdienste.

Die zweite Kategorie, in der wir sagen, dass wir einige Spezifikationen haben, wäre Carrier Ethernet. Kürzlich haben sich TM Forum und MEF zusammen mit Betreibern zusammengetan, um die Lifecycle Service Orchestration-API zu definieren, die sich speziell auf die Carrier-Ethernet-Dienste konzentriert.

Die dritte Kategorie, in der wir konkurrierende Schnittstellen sehen, wäre ein Beispiel: IP-Adressverwaltung, Abrechnung, VNF-Lebenszyklusverwaltung, Netzwerkvirtualisierung oder Orchestrierung. Wenn physische Netzwerkfunktionen und virtuelle Netzwerkfunktionen zusammenarbeiten müssen, müssen wir außerdem eine Reihe von Anpassungen an diesen konkurrierenden APIs vornehmen. Um auf Ihre Frage zurückzukommen: „Wie lösen wir dieses Problem konkurrierender APIs?“, Könnte eine der Lösungen offene APIs mit Microservices-Architektur sein, obwohl die Open-API-Einführung in der Branche nach wie vor in weiter Ferne liegt.

Clarence: Und das ist die eigentliche Frage. Kann die Industrie diese konkurrierenden Schnittstellen tatsächlich zu einem einzigen Gewinner zusammenführen, oder muss es nur eine Reihe von Schnittstellen geben, mit denen wir uns weiterentwickeln?

Hema: Es ist also definitiv eine Zusammenarbeit zwischen Branchengremien erforderlich, und geschieht bereits in gewissem Umfang. Kürzlich haben wir gesehen, dass ONAP zusammen mit der Linux Foundation mit MEF zusammenarbeitet, um Lifecycle Service Orchestration-APIs zu definieren. Sie konzentrieren sich speziell auf die Northbound-Schnittstelle zwischen dem Orchestrator und dem OSS/BSS-Stack.

Wie bereits in der vorherigen Antwort erwähnt, definieren MEF, TM Forum und Betreiber die Lifecycle Service Orchestration-API speziell für Carrier-Ethernet-Dienste. Wenn die Lösungen ausgereift sind, werden offenere APIs verfügbar sein. Die Betreiber beginnen auch mit der Einführung dieser APIs, anstatt ihr Entwicklungsbudget in diese APIs zu investieren. Sobald die Betreiber mit der Einführung beginnen, wird es eine stärkere Verschmelzung dieser konkurrierenden Schnittstellen geben.

Clarence: Gibt es Risiken oder Belohnungen, um diesen Kampf zu gewinnen, und wie würden Sie in der Zwischenzeit mit Ihrem Produkt vorgehen?

Hema: Im SDN/NFV-API-Entwicklungsbereich gibt es mehrere Ökosystemakteure. Einer der Schlüsselakteure ist der Service Provider, der Zweite die Infrastrukturanbieter oder die Hypervisoren, der dritte Anbieter der Netzwerkgeräte, der vierte die Systemintegratoren und der fünfte die Standardbehörden. Je nachdem, auf welchen Ökosystemspieler wir uns beziehen, wird es Risiken und Belohnungen geben. Konzentrieren wir uns also auf die Belohnungen für die Dienstanbieter.

Die wichtigste Belohnung wird die Beweglichkeit, die betriebliche Effizienz sowie die Zeit bis zur Marktreife sein. Im Idealfall was wir auf dem Markt mit unserer Kundenbasis sehen, dauert es etwa ein bis drei Monate, um eine Dienstleistung zu erbringen. Hauptsächlich deshalb, weil dies die Zeitspanne ist, die für die Integration des Multi-Vendor-, Multi-Domain- und Multi-Cloud-Ökosystems erforderlich ist. Die zusätzliche Belohnung wäre eine Kostenersparnis, da die Betreiber nun diese verfügbaren APIs direkt verwenden können. Das Risiko besteht darin, dass diese APIs aufgrund des IT-Overheads und der Sperrung des Anbieters nicht verfügbar sind.

Clarence: Werden die offenen APIs also Zugang zu Carrier-Grade-Netzwerklösungen erhalten, oder handelt es sich um eine vom Hersteller entwickelte API?

Hema: Ja, also offene APIs in der Netzwerkvirtualisierungsbranche haben sich vor allem aufgrund der White-Box-Appliances durchgesetzt, aber wir sehen immer noch Probleme im Zusammenhang mit der Sicherheit und der Carrier-Qualität. Mit Microservices-Architektur glauben wir, dass beide verwendet werden können. Herstellerspezifische APIs können sich auf die Kommunikation zwischen Komponenten konzentrieren, während sich offene API-Initiativen stärker auf benutzergesteuerte Dienste und Funktionen konzentrieren können.

Clarence: Was sind die Haupttreiber für Open-API-Initiativen?

Hema: Wir sehen drei Haupttreiber. Einer ist die digitale Transformation. Innerhalb der digitalen Transformation ist es das Kundenerlebnis; es sind interne Vorgänge; und natürlich das Partner Channel Management. Der zweite Schlüsseltreiber ist eine 5G-bezogene Netzumwandlung, und der dritte sind die IoT-Dienste. Zusammen drängen diese drei Treiber auf die Annahme offener API-Initiativen.

Clarence: Nun, wir brauchen dich wieder um mehr über den Kampf zu sprechen, während er sich entwickelt. Vielen Dank, Hema Kadia, dass Sie bei uns waren.

Hema: Vielen Dank, Clarence. Ich weiß es wirklich zu schätzen.

Clarence: Und danke fürs Zuschauen. Wir würden gerne von Ihnen hören! Nehmen Sie über Facebook oder Twitter Kontakt mit uns auf und Sie können weitere Videos auf TIANow.org und auf unserem YouTube-Kanal sehen.

0 Comments

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

footer logo

Log in with your credentials

Forgot your details?