Tomasz Zajda - Fotolia

Open Service Broker API soll Service-Integration in Kubernetes erleichtern

Mit zunehmender Reife von Kubernetes wirft die Plattform neue Fragen auf. Eine davon könnte die Integration der Open Service Broker API beantworten.

Kubernetes wurde als internes Google-Tool zur Orchestrierung von Linux-Containern ins Leben gerufen und ist in der offiziellen Version erst zwei Jahre alt, gilt inzwischen aber als De-facto-Standard zur Container-Orchestrierung. Seit der Veröffentlichung durch Google wurde Kubernetes im Rahmen der Cloud Native Computing Foundation (CNCF) kontinuierlich weiterentwickelt und steht derzeit in Version 1.6 zur Verfügung.

Trotzdem Kubernetes inzwischen in unzähligen Produktivumgebungen im Einsatz ist, gibt es noch immer viele Problemstellen, die den Einsatz der Orchestrierungsplattform erschweren. Eine davon versucht die Community rund um die CNCF jetzt über die Integration der Open Service Broker API (OSBAPI) zu beheben.

Was ist die Open Service Broker API?

Wie Kubernetes ist auch die Open Service Broker API eine noch sehr junge Technologie, nämlich eine erst im Dezember 2016 offiziell veröffentlichte Programmierschnittstelle, die allerdings bereits seit 2013 im Rahmen der Cloud Foundry Foundation entwickelt und verwendet wird. Wie die später unter maßgeblicher Beteiligung von Google gegründete Cloud Native Computing Foundation hat auch die vor allem durch VMware geprägte Cloud Foundry Foundation ganz allgemein das Ziel, die Nutzung der Cloud in Enterprise-Umgebungen voranzubringen.

Die Open Service Broker API wird also intern im Rahmen der Cloud Foundry Foundation schon seit 2013 genutzt, wurde aber erst Ende 2016 auch für andere Projekte und Plattformen geöffnet. Während die API-Spezifikationen auch weiterhin von der Cloud Foundry Foundation verwaltet werden, soll die Öffnung der OSBAPI auch andere Unternehmen in die Lage versetzen, über sogenannte Service-Broker Applikationen und Services für Cloud-Plattformen jenseits von Cloud Foundry zugänglich zu machen.      

Offiziell arbeiten derzeit Fujitsu, Google, IBM, Pivotal, Red Hat und SAP an der Weiterentwicklung der Open Service Broker API, um beispielsweise IBM- oder SAP-Services über eine einheitliche API-Spezifikation auf Plattformen wie Cloud Foundry oder OpenShift von Red Hat zur Verfügung zu stellen. Im Kern geht es also darum, Anwendungsentwicklern ein einheitliches API-Set an die Hand zu geben, mit dem sich Applikationen auf unterschiedlichsten Cloud-Plattformen integrieren lassen.

Kubernetes und die fehlende Service-Integration

Wie sich im Rahmen der CloudNativeCon und KubeCon 2017 Ende März in Berlin zeigte, steht die Kubernetes-Community mit zunehmender Reife des Projekts und dem Einsatz von Kubernetes in immer mehr Produktivsystemen vor dem wachsenden Problem, dass Kubernetes genau eine solche einfache Service-Integration noch fehlt.

Die OSBAPI füllt diese Lücke offenbar so ideal, dass es in den vergangenen Monaten gleich zwei Ansätze auf Basis des Cloud-Foundry-Projektes gab: Einmal den Alleingang der kürzlich von Microsoft übernommenen Firma Deis, deren Produkt Steward auf der OSBAPI basiert, und parallel dazu ein etwas später aus der Community hervorgegangener gemeinsamer Ansatz unterschiedlicher Unternehmen, der schließlich in der Gründung der Special Interest Group (SIG) Service Catalog gipfelte.

Zukünftig, so war von Deis während der CloudNativeCon zu hören, soll die Arbeit an Steward aber in die SIG Service Catalog einfließen, der neben Red Hat, Google und IBM inzwischen auch Deis angehört. Eine unterschiedliche Implementierung derselben Technologie, eine der großen Todsünden von Open-Source-Software, dürfte somit also vermieden werden. Gegen eine Community-Initiative so wichtiger Unternehmen wie Google, Red Hat und IBM hätte Deis langfristig aber wohl auch wenig entgegenzusetzen gehabt.     

OSBAPI erweitert Kubernetes um zusätzliche Services

Derzeit befindet sich die OSBAPI-Implementierung in Kubernetes noch in der frühen Alpha-Phase. Zukünftig sollen aber die gleichen Funktionen zur Verfügung stehen, wie etwa auf der Cloud-Foundry-Plattform. Chip Childers, CTO der Cloud Foundry Foundation, und Paul Morie, Principal Software Engineer bei Red Hat, zeigten in einem gemeinsamen Vortrag auf der CloudNativeCon/KubeCon 2017, wie sich die Servicebereitstellung für Kubernetes über die Open Service Broker API zukünftig wesentlich einfacher gestalten lassen dürfte.

Stand heute, so die beiden während ihres Vortrages, müssten Entwickler beispielsweise Datenbanken manuell bei Administratoren oder Kubernetes-Operatoren anfragen. Diese würden ihnen anschließend ebenso manuell Zugangsdaten und Konfigurationsdetails wie IP-Adressen oder Ports übermitteln, was fehleranfällig und wenig zuverlässig ist.

Über die API-Spezifikation der Open Service Broker API, so die Quintessenz ihres Vortrags, könnten Entwickler zukünftig die einheitliche OSBAPI nutzen, um ohne Interaktion mit Administratoren selbstständig Datenbankinstanzen anzufragen, aufzusetzen und in ihre Anwendungen einzubinden.

Service-Katalog als Rückgrat der Open Service Broker API

Ein ähnliches Beispiel zeigte Gabe Monroy, CTO von Deis, während seines Vortrags zu Steward. Sein Schwerpunkt lag allerdings auf dem hinter der OSBAPI stehenden Service-Katalog, der die über Service-Broker gebündelten externen Applikationen und Dienste zur Verfügung stellt. Dieser Service-Katalog wird nach aktuellem Entwicklungsstand als eigene API-Surface mit eigenem Kubernetes Controller im Kubernetes-Cluster installiert.

Anschließend werden Service-Broker gestartet, die selbstständig über die einheitliche API-Spezifikation nach kompatiblen Services und Anwendungen suchen und diese über den Service Catalog zur Verfügung stellen. In Kubernetes selbst werden diese Services als eigene Service-Klassen abgerufen. Service-Broker können dabei sehr flexibel programmiert werden und sowohl speziell für eine Anwendung als auch für mehrere Anwendungen und gleichzeitig für eine oder für mehrere Plattformen funktionieren. Eines der nächsten Ziele bei der Weiterentwicklung der OSBAPI ist zudem ein Service Broker SDK, mit dem die Entwicklung eigener Service-Broker vereinfacht werden soll.

Um die über die Service-Broker im Service-Katalog aufgelisteten Services nutzen zu können, werden schließlich Manifest-Dateien erstellt, in denen die Service-Klassen referenziert werden. Das eigentliche Ziel dabei, so Gabe Monroy in seinem Vortrag, sei der Wechsel von impliziten Bindings, also vereinfacht gesagt „Verbindungen“ oder Zuordnung von Anwendung und Service per manueller Übermittlung der Service-Konfiguration, hin zu expliziten Bindings, bei denen die Konfigurationsinformationen direkt über die API übermittelt werden. Damit, so sein Fazit, ließen sich Anbieter von Services (wie Datenbanken oder SaaS-Anwendungen) von deren Konsumenten, also Anwendungsentwicklern, trennen.

Vom Infrastruktur- zum Service-Management

Von einem strategischen Blickwinkel aus betrachtet, lässt sich die OSBAPI-Implementierung in Kubernetes als weitere Ausdrucksform des Trends weg vom Infrastruktur- und hin zum Service-Management interpretieren. In modernen, heterogenen und hybriden IT-Umgebungen müssen Services und Applikationen schließlich auf unterschiedlichsten Plattformen eingebunden werden können und dabei auch reibungslos funktionieren. Da ist es nur logisch, den Management-Fokus von einzelnen Infrastrukturplattformen weg und direkt in Richtung der eigentlich relevanten Services zu richten.

Die Open Service Broker API ermöglicht schon heute die einheitliche Nutzung unterschiedlichster Services über verschiedene Plattformen hinweg. Über die Integration der OSBAPI in Kubernetes könnten entsprechende Services zukünftig ebenso einfach auf Googles Orchestrierungsplattform zur Verfügung stehen, was letztlich beiden Seiten hilft: Kubernetes erhält so die Möglichkeit zur einfachen Service-Integration, die bereits weit über die Open-Source-Community hinaus genutzt wird, während das OSBAPI-Projekt seine Reichweite um die zunehmend populärer werdende Kubernetes-Plattform erweitern kann.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im April 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Cloud-Anwendungen

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close