"Oracle Code One"-Tagebuch – Tag 3: Serverless

Liebes Tagebuch,

heute hatte ich das Glück, mich länger mit Chad Arimura (Vice President Serverless, Oracle) unterhalten zu können. Chad ist bei Oracle für das Fn Project, Oracles Serverless-Angebot, zuständig. Fn ist eine quelloffene Container-native-Serverless-Plattform, die im eigenen Rechenzentrum on-premise oder aber in jeder beliebigen Cloud betrieben werden kann.

Da als Basis für die Serverless Functions Docker-Container verwendet werden, unterstützt Fn Project praktisch jede Programmiersprache, die in einem Docker-Container lauffähig ist. Für einige Programmiersprachen gibt es zusätzlich Function Development Kits (FDKs), welche die Entwicklung von Fn Functions deutlich vereinfachen. Als "First Class Citizens" werden derzeit neben Java die Sprachen Go, Python, Node.js und Groovy unterstützt.

Interview

Lars Röwekamp: Hallo Chad, lass uns gleich mit der ersten Frage starten: Fn Project wurde genau vor einem Jahr veröffentlicht. Was sind aus deiner Sicht die wichtigsten Erweiterungen der letzten zwölf Monate?

Chad Arimura: Seit dem Launch im Rahmen der JavaOne 2017 haben wir vor allem an der Stabilität, der Zuverlässigkeit und der Skalierbarkeit des Frameworks gearbeitet. Zusätzlich haben wir viel Energie in die Ausarbeitung der Plattform-APIs gesteckt, um so das Hosten und Managen der Plattform zu erleichtern. Oracle plant in der ersten Hälfte 2019, mit Oracle Functions eine vollständig gemanagte Version des Frameworks in der Oracle-Cloud anzubieten.

Röwekamp: Das ist interessant. Bisher war sich zumindest die deutsche Serverless-Community uneins, ob man eine Plattform wie Fn Project als Serverless bezeichnen kann, wenn man sie zwingend selbst hosten muss.

Arimura: Diese Diskussion gibt es nicht nur in Deutschland. Aus Sicht der Function-Entwickler ist es auf jeden Fall als Serverless zu bezeichnen. Aus Betriebssicht dagegen mag es unterschiedliche Meinungen geben. Meiner Meinung nach muss man hier die unterschiedlichen Level unterscheiden. Aber genau in der Möglichkeit, unser Framework sowohl in einer Public Cloud als auch on-premise zu betreiben, sehen wir einen großen Mehrwert den meisten unserer Mitbewerber gegenüber. Das bestätigen uns auch immer wieder unsere Kunden.

Röwekamp: Aktuell liegt Fn Project in der Version 0.75 vor. Das schreckt sicherlich den einen oder anderen potenziellen Interessenten vor einem Einsatz im produktiven Umfeld ab. Wird es bis zum Launch von Oracle Functions auch eine Version 1.0 von Fn Project geben?

Arimura: Exakt das ist unser Plan. Wir wollen bis spätestens zum Release von Cloud Functions auch eine Version 1.0 von Fn Project bereitstellen. Zusätzlich gehen wir davon aus, dass neben Oracle auch weitere Partner von uns die Plattform als gemanagten Service anbieten werden. Das Team von Oracle Functions und Fn Project ist übrigens dasselbe. Beide Welten partizipieren daher stark voneinander. Anders formuliert wird der Mehrwert von Oracle Functions vor allem in den weltweit hochverfügbaren Rechenzentren von Oracle liegen. Die technische Basis des Frameworks dagegen wird in beiden Welten identisch sein.

Röwekamp: Wo siehst du weitere Mehrwerte eurer Plattform gegenüber denen eurer Mitbewerber?

Arimura: Der erste weitere Mehrwert ist sicherlich darin zu sehen, dass Fn Project Open Source ist und dank Docker auf ein offenes Protokoll setzt. Während bei den anderen Anbietern ein Zip-File in die spezielle Runtime geladen werden muss, stellen wir die Docker Contracts zur Verfügung. So können bereits existierende, komplexe Libraries – wie die automatische Erkennung von Nummernschildern – sehr einfach via Docker-Container als Serverless Function zur Verfügung gestellt werden. Ein weiterer Mehrwert ergibt sich durch die angedachte Integration mit anderen Oracle-Cloud-Services. Wir planen Event-Streams für viele der Oracle-Cloud-Services anzubieten. Erstellt man zum Beispiel in Oracle HCM (Human Capital Management) einen neuen Eintrag, so stößt dieser ein Cloud-Event an, welches wiederum von einer Oracle Function entgegengenommen werden und dort weitere Prüfungen oder Verarbeitungen außerhalb des HCM auslösen kann.

Röwekamp: Die von dir erwähnte Integration mit Oracle--CloudServices ist sicherlich ein wichtiger Mehrwert für Kunden, die bereits stark auf Oracle-Produkte setzen. Was aber ist mit der restlichen Welt. Ist diese außen vor?

Arimura Nein natürlich nicht. Wir arbeiten derzeit gemeinsam mit der Serverless Working Group der Cloud Native Computing Foundation (CNCF) an einer Standardisierung von Cloud-Events. Mit diesen Events können dann Ereignisse von Services beliebiger anderer Clouds verarbeitet werden.

Röwekamp: Ein neutrales Event-Modell, mit dessen Hilfe Cloud-übergreifend Service-Events ausgetauscht werden können? Das hört sich gut an. Lass uns auf ein weiteres Problem der Serverless-Welt zu sprechen kommen. Nahezu alle Anbieter von Serverless Functions rechnen aktuell nach einem Pay-per-use-Modell ab. Dies lässt Serverless Functions für langlaufende Aktionen eher unattraktiv erscheinen. Genau aus diesem Grund bietet zum Beispiel AWS für die Orchestrierung ihrer Lambdas die AWS Step Functions an. Ist für Fn Project etwas Ähnliches geplant?

Arimura: In der gemanagten Variante, also Oracle Functions, wird es, wie bei allen anderen Providern auch, definitiv ein Timeout für die einzelnen Functions geben. Verwendet man dagegen die Open-Source-Variante, lässt sich natürlich das Timeout beliebig setzen. Ob dies sinnvoll ist, sei einmal dahingestellt. Für wirklich langlaufende Operationen und die Orchestrierung von Serverless Functions, also für Workflows, haben wir derzeit eine rudimentäre Lösung namens Fn Flow. Unser eigentliches Ziel ist aber auch hier, gemeinsam mit der Serverless Working Goup der CNCF eine standardisierte Lösung zu spezifizieren und diese im Anschluss umzusetzen.

Röwekamp: Ich habe jetzt richtig Lust bekommen, einmal ein wenig mit Fn Project herumzuspielen. Abschließend also die Frage, wie und wo ich am besten starte.

Arimura: Am besten gehst du einfach direkt auf fnproject.io oder unser GitHub-Projekt und folgst dort den "Getting started"-Anweisungen. In weniger als zwei Minuten solltest du dann das Framework installiert und die erste Serverless Function deployt und aufgerufen haben: fn start, fn init, fn deploy und fn invoke – das ist schon alles. Für eine etwas ausgereiftere Variante, welche Fn Project auf Kubernetes aufsetzt, stellen wir ein Helm Chart zur Verfügung. Ab Q1 oder Q2 2019 kannst du natürlich auch einfach auf Oracle Functions in der Oracle -Cloud aufsetzen. Aber so lange möchtest du sicherlich nicht warten.

Röwekamp: Besten Dank für das Interview und deine Zeit, Chad.

Arimura: Sehr gern. Und viel Spaß beim Herumspielen mit Fn Project!

... und Tschüss

Liebes Tagebuch, das war es erst einmal für mich auf der Code One 2018. Auch wenn ich mich nach wie vor nicht wirklich an den neuen Namen gewöhnen kann und in den vielen, vielen Gesprächen vor Ort immer wieder den Namen JavaOne verwendet habe, hat die Konferenz wirklich Spaß gemacht.

Inhaltlich tut die thematische Erweiterung der Konferenz gut. Die neuen Themenwelten wurden so gewählt, dass sie auf jeden Fall auch für Java-Entwickler von Interesse sind. Die IT-Landschaft ist in den letzten Jahren deutlich heterogener geworden. Da reicht oftmals die reine Kenntnis (s)einer Programmiersprache nicht mehr aus. DevOps, Container, Cloud, KI, Modern Web, all dies sind Themen, an denen in der Zukunft kaum ein Weg vorbeiführen wird. Dies gilt zumindest für Entwickler, die in einem zeitgemäßen Projektumfeld aktiv sind.

Mehr dazu aber in den nächsten Blogbeiträgen ()