Adobe I/O

Ich versuche nun zuerst, diese Begriffe nachfolgend einzuordnen, um einen besseren Überblick zu erhalten.

Adobe I/O versteht sich als Plattform für Entwickler und Systemintegratoren rund um die von Adobe angebotenen Produkte und Services. Die Adobe I/O Plattform bietet beim Einstieg die folgenden Bereiche:

Die Plattform wird über die Webseite www.adobe.io präsentiert. Das ist zudem die erste Anlaufstelle für alle, die sich mit der Plattform beschäftigen wollen. Auf der Seite selbst findet man verschiedenste Dokumentationen über die angebotenen Dienste und Schnittstellen. Ein weiterer umfangreicher Bestandteil sind die sogenannten Code Labs, in denen man für unterschiedliche Anwendungsszenarien ausführliche Tutorials findet, siehe https://www.adobe.io/app-builder/docs/resources/

Auf dieser Webseite befindet sich der Einstieg in die sogenannte Adobe Developer Konsole. Über die Adobe Developer Konsole kann man mit Hilfe von Templates eigene Integrationsprojekte erstellen. Bei der Verwendung dieser Templates werden direkt verschiedene sogenannte Workspaces angelegt. In einem der Workspaces werden die Services gebündelt, die man für die Entwicklung einer Anwendung bzw. Integration von Adobe Services benötigt. Klassischerweise werden Workspaces für „Stage“ und „Production“ erstellt. Aber auch für die Entwicklung kann man eigene Workspaces erstellen lassen. Neben der Möglichkeit, Templates zu nutzen kann, man aber auch auf der grünen Wiese starten und sich seine Workspaces selbst anlegen. 

Auf der Ebene der Workspaces befinder sich auch die Zugriffsverwaltung. Alle so gebündelten Services und APIs teilen sich pro Workspace die gleichen Zugangsdaten, meist JSON Web Token (JWT) Authentication. Das verringert gerade bei der Verbindung von verschiedenen APIs den Integrationsaufwand. Die Templates binden ebenfalls die Adobe I/O Runtime als zentralen Bestandteil in die Workspaces ein. Weitere Services und APIs muss man nachfolgend über die Developer Konsole im Browser quasi zusammenklicken.

Adobe I/O fungiert als API Hub für die verschiedenen Services und APIs, die im Adobe Kosmos angeboten werden. Fügt man einem der oben genannten Workspaces einen Service hinzu, stellt man fest, dass der Katalog der verfügbaren APIs mittlerweile eine ganze Reihe unterschiedlichster Anwendungen beinhaltet. Das Spektrum ist inzwischen enorm und erstrecht sich von einer User Management API, mit dessen Hilfe man auf Benutzerinformationen zugreifen kann, bis hin zu KI-basierten Services, wie beispielsweise die Photoshop API zum Freistellen von Bildern.

Hier werden auch die unterschiedlichen Lösungen von Adobe miteinander verknüpfbar gemacht. So findet man im Katalog der angebotenen Services auch die APIs von Adobe Analytics, Adobe Campaign oder Adobe Target. Natürlich reicht es nicht aus, sich die Services „zusammenzuklicken“. Es bedarf noch einer Integration, in der man z. B. die verschiedenen APIs anspricht. Eine solche Integration wird im Adobe I/O Umfeld in einer sogenannten Firefly Application entwickelt und gekapselt.

Mit App Builder hat Adobe eine Entwicklungs- und Laufzeitumgebung geschaffen, in der man die Integrationen rund um Adobe I/O schnell und zielgerichtet umsetzen und auch betreiben kann. Dabei sprechen wir von einer Entwicklertätigkeit, denn an dieser Stelle verlassen wir den Pfad des einfachen Zusammenklickens.

Aber fangen wir von vorne an: Project Firefly hieß das Label, unter dem Adobe verschiedene Bestandteile zusammengefasst hat. Zukünftig wird das Ganze unter den Namen App Builder zu finden sein. Folgende Teile fallen darunter:

• Adobe I/O Runtime
• Adobe I/O Events
• Adobe I/O CLI
• Adobe SDK

Die Adobe I/O Runtime ist dabei der zentrale Bestandteil und quasi die Laufzeitumgebung, die Adobe bereitstellt, damit die entwickelten Integrationen betrieben werden können. Über sogenannte „serverless functions“ kann man so die Adobe Experience Platform und deren Services erweitern oder miteinander verbinden.

Die Adobe I/O Laufzeitumgebung basiert auf Apache OpenWhisk und Node.js. OpenWhisk ist eine serverlose Open-Source Plattform, die Funktionen als Reaktion auf bestimmte Events ausführen kann. OpenWhisk bzw. die Adobe I/O Runtime verwaltet die Infrastruktur, Server und Skalierung mit Hilfe von Docker Containern. Dadurch muss man sich bei der Entwicklung nicht um Aspekte der Skalierung kümmern, sondern kann sich auf die Lösung des Problems konzentrieren.

Da die Plattform auf Node.js basiert, findet die Entwicklung meist in JavaScript statt. Die Plattform unterstützt dabei ein Programmiermodell, in dem Anwendungscode in Funktionen gekapselt wird. Diese Funktionen nennt man OpenWhisk Actions. Diese Funktionen werden meist über Trigger (z. B. Events) oder HTTP-Anfragen ausgelöst. So kann man z. B. eine Funktion entwickeln, die über JavaScript und einer entsprechenden Client-Bibliothek die Photoshop API von Adobe anspricht. Das Ganze kann dann genutzt werden, um aus AEM heraus über HTTP-Anfragen beispielsweise Renditions zu erzeugen. Der Vorteil dieser Herangehensweise liegt auf der Hand: Die einzelnen Funktionen sind gekapselt und werden über die Adobe I/O Runtime automatisch skaliert (Function-as-a-Service). Die Last wird so vom AEM System auf die Adobe I/O Runtime verteilt.

Neben diesen Actions können auch Webanwendungen über die Adobe I/O Runtime deployed und betrieben werden. Adobe nutzt dafür eigens entwickelte React Komponenten, die auf dem Design System von Adobe basieren. Die so entwickelten Weboberflächen kann man dann z. B. nutzen, um die oben genannten Actions zu testen. Generell kann man hier viele verschiedene Use Cases mit abbilden. Inwiefern es Sinn macht, eine Webanwendung über die Adobe I/O Runtime zu betreiben, muss man aber im Einzelfall evaluieren. Bei Anwendungen, die als Web-Frontend für die „Serverless Functions“ fungieren, macht dies am meisten Sinn. 

Ein weiterer Bestandteil der Plattform ist Adobe I/O Events. Adobe I/O Events ist integriert in die Adobe I/O Runtime und ermöglicht auf Events aus der Experience Platform zu reagieren. So ist es z.B. möglich, auf ein Deployment im Cloud Manager von AEM as a Cloud Service zu reagieren. Man kann sich über einen Webhook für diese Events registrieren. Darüber können dann beispielsweise automatische Build-Benachrichtigungen für Microsoft Teams erzeugt werden. Adobe bietet derzeit eine ganze Reihe von Events an, auf die man reagieren kann. Wer mehr über die spezifischen Events erfahren will, sollte hier fündig werden: https://www.adobe.io/apis/experienceplatform/events/docs.html#!adobedocs/adobeio-events/master/using/using.md

Um die Entwicklung zu beschleunigen, bietet Adobe neben der Plattform auch eine ganze Reihe fertig entwickelter Bibliotheken. Alle diese Bibliotheken sind NPM-Module und lassen sich einfach in die Anwendung integrieren.

Nachfolgend eine Liste der meiner Meinung nach interessantesten Bibliotheken:

• Adobe / aio-lib-state
  API für den Cloud/State Storage

https://github.com/adobe/aio-lib-state

• Adobe / aio-lib-files

Abstraktion des Cloud Storage zu einer Dateisystem ähnlichen API
https://github.com/adobe/aio-lib-files

• Adobe / aio-lib-photoshop-api
  SDK für die Photoshop API von Adobe

https://github.com/adobe/aio-lib-state

• Adobe / aio-sdk

Modul, das alle wichtigen Adobe I/O SDKs enthält

https://github.com/adobe/aio-sdk

• Adobe / aio-lib-cloudmanager
  SDK für die Cloud-Manager API

https://github.com/adobe/aio-lib-cloudmanager

• Adobe / aio-lib-events
  SDK für die Adobe I/O Events API

https://github.com/adobe/aio-lib-events

Adobe ist bemüht, mehr Bibliotheken zu entwickeln und zu veröffentlichen. Diese werden dann auf GitHub quelloffen veröffentlicht. Wir haben in der letzten Zeit beobachtet, dass Adobe diesen Weg immer mehr verfolgt. Auch die Dokumentationen und sämtliche Tutorials werden mittlerweile offengelegt. 

Natürlich geht keine Entwicklung ohne ein Command Line Interface (CLI). Adobe hat mit dem Adobe I/O CLI ein Tool, welches ein zentrales Tool der Entwicklung ist und die Entwicklung in vielen Aspekten unterstützt: So lassen sich die entwickelten Funktionen mit der Adobe I/O CLI kompilieren, deployen und testen. Ebenso findet die Projektinitialisierung über die Kommandozeile statt. Das Kommandozeilen-Interface lässt sich über Plug-ins erweitern. Adobe bietet einige Plug-ins an, womit sich z. B. im Umfeld des Cloud Managers einige Dinge automatisieren lassen, wie beispielsweise das Triggern von Builds oder das Aktualisieren von Umgebungen. Das CLI spielt also nicht nur bei der Entwicklung von Apps und Servless Functions eine Rolle; es wird generell im Umgang mit den Cloud-Diensten von Adobe verwendet. 

Zusammengefasst kann man sagen, dass Adobe mit Adobe I/O eine sinnvolle, cloudbasierte Erweiterungsmöglichkeit der Experience Plattform rund um AEM geschaffen hat. Es ist absehbar, dass viele Customizations, die früher direkt im AEM-Umfeld angesiedelt waren, nun über Adobe I/O und die dazugehörige Plattform abgebildet werden. Die Vorteile liegen auf der Hand: Die Architektur ist skalierbar, service-orientiert und einzelne Erweiterungen lassen sich in Microservices kapseln. Die Plattform erleichtert zudem erheblich die Verbindung der einzelnen Services und APIs der Experience Cloud.