Die AEM Autoren-Umgebung vereint auf einer OSGi Architektur alle für das Bearbeiten von Content notwendigen Services inkl. des Datenspeichers. Diese Architektur erschwert jedoch das Clustern der Umgebung, da die Daten zwischen den Servern synchronisiert werden müssen. Eine selten genutzte Alternative ist, die Daten in einer externen Datenbank zu speichern. Beide Ansätze haben sich in der Praxis jedoch nicht bewährt und die AEM Autoren-Umgebung wird bei meist als nicht-geclustertes System betrieben.
AEM on premise, as Managed Service oder as a Cloud Service
Was ist das richtige für uns?
Seit inzwischen einem Jahr ist Adobe Experience Manager (AEM) as a Cloud-Service verfügbar und Adobe spricht dabei von der nächsten AEM Cloud-Native Generation. Aber was bedeutet das eigentlich? Ist es mehr, als ein neues Buzzword, um AEM besser zu verkaufen? In diesem Blog-Beitrag werde ich aufzeigen, dass es sich dabei um einen komplett neuen Ansatz handelt, wie AEM designed, implementiert, deployed und betrieben wird. Ich werde dabei auch auf die schon länger bestehenden Lösungen AEM on Premise und AEM as a Managed Service eingehen und dabei Hintergründe, Unterschiede und Anwendungsbereiche erklären.
Evolution von AEM in der Cloud
Der Eindruck, dass das AEM Cloud Angebot von Adobe revolutionsartig entstanden ist, ist falsch. Es war vielmehr eine Evolution über mehrere Jahre hinweg. Beginnend mit der Übernahme der Firma Day Software durch Adobe im Jahr 2010, über das Angebot von AEM as a Managed Service in 2014 bis hin zu AEM as a Cloud Service im vergangenen Jahr.
AEM as Managed Service
AEM as Managed Service ist ein Angebot von Adobe, bei dem Adobe die komplette AEM Infrastruktur für den Kunden in der Amazon Cloud betreibt. Die Lösung wurde im Laufe der Jahre um den Cloud Manager erweitert und trägt seitdem den etwas sperrigen Namen AEM as a Managed Service with Cloud Manager. Das Alleinstellungsmerkmal des Produkts ist die hohe Verfügbarkeit von bis zu 99,99% der Publish-Umgebungen und 99,9% der Autoren-Umgebungen.
AEM as a Cloud Service
AEM as a Cloud-Service ist das Software as a Service Angebot für AEM von Adobe. Adobe stellt dabei eine komplette AEM Umgebung als Cloud-Service zur Verfügung. Der Kunde hat dabei nur noch Zugriff über den Web-Browser.
Im Unterschied zu AEM as a Managed Service unterscheidet sich AEM as a Cloud-Service sowohl in der Architektur als auch beim Deployment von der on Premise Installation.
Adobes Versprechungen
Aufgrund des neuen Cloud Ready Ansatzes gibt Adobe für AEM as a Cloud-Service vier Versprechen, die sowohl für Kunden mit kleinen als auch großen Installationen interessant sind:
- Always On
Aufgrund der neuen Service-Architektur von AEM als Cloud-Service gibt es keine Ausfallzeiten mehr. Weder für die Autoren bei der Bereitstellung von Inhalten, noch beim Ausliefern von Content für die Besucher.
- Always at Scale
Aufgrund der Container basierten Bereitstellung von AEM als Cloud-Service, kann die Infrastruktur jederzeit automatisch nach oben und unten skalieren.
- Always Current
Mit Hilfe der enthaltenen Continous Delivery Pipeline für die AEM Code Base kann die PLattform mit automatisierten Updates mehrmals im Monat aktualisiert werden. So gehören teure und komplizierte AEM Upgrades der Vergangenheit an.
- Always Evolving
AEM als Cloud-Service entwickelt sich täglich weiter. Inhalt, Code und Konfigurationen werden ständig und anhand von Best Practices überprüft.
Architektur
Wie bereits angedeutet gibt es deutliche Unterschiede zwischen der „klassischen Architektur“ bei AEM on Premise bzw. AEM as a Managed Service und der neuen Cloud Native Architektur bei AEM as a Cloud-Service.
Klassische AEM Architektur
Bei der klassischen AEM Architektur gibt es drei Arten von Systemen: AEM Author, AEM Publisher und AEM Dispatcher.
Die AEM Publish-Umgebung stellt ebenfalls auf OSGi basierend alle Services für das Ausliefern von Content bereit. Ein Publish-Cluster ist jedoch deutlich einfacher zu betreiben, da in dieser Umgebung kein Content bearbeitet wird und daher keine Änderungen synchronisiert werden müssen.
Der AEM Dispatcher steht meist vor einer Publish-Instanz, zum Teil auch vor einer Autoren-Instanz, um statische Inhalte zu cachen und so die AEM Server zu entlasten und die Performance zu erhöhen.
Bei AEM as a Managed Service with Cloud Manager gibt es zusätzlich noch die Komponenten Cloud Manager, Adobe Identity Management Service (IMS) und den CI/CD Service. Der Cloud Manager ist das Interface des Systems für den Kunden. Darüber kann auf Log-Dateien zugegriffen, Deployments mit Hilfe des CI/CD Services angestoßen oder Rechte vergeben werden. Denn ein direkter Zugriff auf die Konsolen ist nicht möglich. Die Authentifizierung erfolgt stets über IMS, der aber auch SSO über Microsoft Azure Active Directory (AD) unterstützt.
Einschränkungen im Cloud Betrieb
Die klassische AEM Architektur verfolgt den monolithischen Ansatz mit einer großen Applikation, die alle benötigten Module, wie Web-Frontend, Datenbank, Asset-Verarbeitung, Workflow-Engine und viele andere enthält. Dadurch ist es in einem Nicht-Cloud-Umfeld sehr einfach, die Applikation zu deployen, zu testen und zu betreiben. Dieser Ansatz erlaubt jedoch nicht, dass AEM effektiv auf einer Cloud-Plattform wie Kubernetes automatisiert betrieben und orchestriert wird.
AEM Cloud Native
Was bedeutet Cloud-Native eigentlich? Die Cloud Native Computing Foundation (CNCF) definiert Cloud-Native wie folgt:
"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."
Basierend auf dieser Definition ist eine Anwendung dann Cloud-Native, wenn diese skalierbar ist und in modernen, dynamischen Umgebungen ausgeführt werden kann. Folgend der Definition ist dies möglich, wenn die Anwendung in Containern betrieben werden kann und über eine Microservice-Architektur verfügt.
Damit eine Anwendung effektiv in Containern automatisiert betrieben und orchestriert werden kann, muss sie den sieben Cloud-native Prinzipien entsprechen. Die klassische AEM Architektur verstößt jedoch sowohl gegen das Single-Concern als auch gegen das Self-Containment-Principle und kann daher nicht effektiv in Containern automatisiert betrieben und orchestriert werden.
Das Single-Concern-Priciple besagt, dass ein Container immer nur eine Aufgabe übernehmen soll. Bei AEM übernehmen die Server jedoch stets alle Aufgaben einer Umgebung. In der Autoren-Umgebung stellt der Server z.B. neben anderen Dingen die Autoren-Oberfläche bereit, kümmert sich um die Replikation der Daten auf die verschiedenen Instanzen, führt Maintenance Aufgaben durch und speichert die Daten. So kann sich ein Problem in einem Aufgabenbereich schnell auf andere Bereiche auswirken. So kann es etwa zu Performanceeinbußen für die Autoren kommen, wenn der Server zeitgleich hochgeladenen Bilder oder Videos verarbeiten muss.
Das Self-Containment-Principle dagegen beschreibt, dass ein Container zur Build Zeit alles enthalten muss, was er beim Betrieb benötigt. So ist sichergestellt, dass jederzeit neue Container gestartet werden können. Dies ist bei der klassischen AEM Architektur jedoch nicht möglich, da der Container Content enthält, der sich im Laufe des Betriebs ändert.
Mit den Erfahrungen aus dem AEM as a Managed Service Angebot und dem Ziel, AEM „Container friendly“ zu gestalten, startete Adobe 2019 das Projekt Skyline. Im Rahmen des Projekts wurde AEM auf eine Micro-Services Architektur umgestellt und die Services, wenn möglich, in eigene Container ausgelagert:
- Orchestration Service
Im Orchestration Service, der die Dispatcher-, Publisher- und Author-Nodes enthält, wurde ein neue Maintenance-Nodes hinzugefügt. Diese kümmern sich um die Datastore Garbage Collection, die Version Purges, Purges des Audit Logs, den Clean-Up der Lucene Binaries, Ad-hoc Task Purges, Workflow Purges und die Project Purges.
- Asset Compute Service
Der Asset Compute Service wurde eingeführt, um die Asset-Verarbeitung vom CMS zu trennen. Er kümmert sich um die Erstellung von Renditions, Integration der KI Features (smart Cropping, Smart Tagging) und bindet eigene Worker ein. Dadurch sind die Ressourcen-belastenden Massen-Uploads vom Authoring getrennt und beeinträchtigen die Performance der Autoren-Umgebungen nicht.
- Content Repository Service
Der Content Repository Service stellt ein zentrales Repository für die mit AEM erstellten und veröffentlichten Inhalte bereit. Das Publisher-Tier liest dabei nur aus dem Repository, während die Autorenebene sowohl liest als auch schreibt. Binäre Dateien speichert das Repository in einen BLOB-Speicher, der ebenfalls von beiden Tiers gemeinsam genutzt wird.
Mit der Einführung des Content Repository Services verabschiedet sich Adobe auch vom alten AEM Prinzip „Everything is content!“ und trennt die Code Base vom CMS-Content. Diese wird daher nicht mehr im zentralen Repository gespeichert, sondern jeder Author- und Publisher-Node speichert den Code selbst.
- Replication Service
Der Replication Service verwaltet die Veröffentlichungen von Inhalten von der Autoren-Instanz an die Publisher-Instanz mithilfe einer Middleware-Pipeline. Einzelne Publisher-Nodes abonnieren dabei die Inhalte, die von den Autorenknoten in die Pipeline verschoben werden.
Mit Abschluss des Projekts im letzten Jahr ist das Produkt AEM as a Cloud Service verfügbar und Adobe selbst bezeichnet diese Lösung als Cloud Ready.
Zusammenfassung
Die neue AEM Cloud-Native-Architektur ist deutlich stabiler und einfacher skalierbar als die AEM Classic-Architektur. Durch Einführung des Content Repository Service und der Trennung von Content und Code Base analog dem Self-Containment-Principle, können Publisher- und Author-Nodes bei Bedarf automatisch erzeugt und auch wieder zerstört werden. So kann sich das System dynamisch an Last-Spitzen anpassen. Durch Auslagern zahlreicher Services aus den Publisher- und Author-Nodes in Microservices gibt es zudem deutlich weniger Störungen im CMS Betrieb.
Release Management
Wie bei der Architektur gibt es auch beim Release Management große Unterschiede zwischen AEM Classic und AEM Cloud Native.
AEM Classic
Bei AEM Classic ist die Custom Code Base der Anwendungen völlig losgelöst von der AEM Code Base. Unabhängig von AEM werden Releases gebaut, getestet und deployed. Die Kompatibilität der Anwendung zu AEM liegt dabei in den Händen der Entwickler. Ebenso muss sich der Betrieb darum kümmern, dass die verschiedenen AEM Umgebungen (Entwicklung, Testing, Produktion) immer auf einem identischen Patch-Stand sind.
Bei den vierteljährlichen Upgrades der AEM Umgebung durch Service Packs mit neuen Features, kleinen Verbesserungen und Bug Fixes muss dann jeweils der vorhandene Custom Code auf Kompatibilität getestet und evtl. angepasst werden. Dies geschieht meist in einem größeren AEM Upgrade Projekt.
AEM Cloud Native
Bei AEM Cloud Native werden von Adobe teilweise täglich Maintenance Updates und monatlich New Feature Updates bereitgestellt. Diese Änderungen liegen zusammen mit dem Custom Code in dem von Adobe bereitgestellten Github. Über den AMS Cloud Manager können Releases erstellt werden und entsprechende Container erzeugt werden. Dies hat den Vorteil, dass die Entwickler laufend Zugriff auf Änderungen von AEM haben und so sofort notwendige Anpassungen durchführen können. Ebenso ist dadurch sichergestellt, dass alle Container immer über das identische Patch Level verfügen. So gehören aufwendige Update Projekte der Vergangenheit an und es sichergestellt, dass die Anwendung immer mit den neuesten AEM Features ausgeliefert wird.
Lizensierung
Bei der Lizensierung der unterschiedlichen Varianten muss man nicht nur zwischen den unterschiedlichen Deployment-Varianten, sondern auch zwischen den einzelnen AEM Produkten Sites, Forms und Assets unterscheiden.
AEM Sites
Während AEM Sites wird bei der on Premise Variante auf Basis von Instanzen und Autoren lizensiert wird, wird die AEM as a Managed Service Lösung auf Basis von Traffic, Anzahl an Usern und des SLAs lizensiert. AEM Sites as a Cloud Service wird dagegen nur auf Basis sogenannter Content Requests lizensiert. Ein Content Request entspricht einem Page View oder 5 API-Calls.
AEM Forms
Bei AEM Forms ist die Lizensierungsmetrik dagegen sehr einheitlich. Sie basiert bei allen Varianten auf den Transaktionen. Nur bei As a Managed Service wird zusätzlich das SLA berücksichtigt.
AEM Assets
Bei AEM Assets wird für alle Varianten die Anzahl der Autoren und der Brandportal User zugrunde gelegt. Bei AEM as a Managed Service wirkt sich zudem der benötigte Speicher und das gewählte SLA aus. Bei AEM as a Cloud Service basiert die Lizenz ebenfalls, neben den Autoren und Brandportal Usern, in einem geringen Maß auf dem Benötigten Speicher.
Zusammenfassung
Zusammenfassend kann gesagt werden, dass nach wie vor alle drei Varianten ihre Daseinsberechtigung haben. On Premise ist für viele deutsche Unternehmen aufgrund von Datensicherheits- und Datenschutzproblematiken immer noch die erste Wahl. Mit AEM as a Managed Service lassen sich auch komplizierte individuelle Anforderungen in der Cloud mit sehr hohem SLA abbilden. AEM as a Cloud Service wird jedoch stetig seinen Footprint vergrößern, da die deutlich modernere Architektur viele bekannte AEM Herausforderungen löst und auch Adobe sich stark in diese Richtung entwickelt. Aktuell gibt es aber für manche Projekte immer noch den ein oder anderen Blocker für die Cloud Native Lösung. Bei der Wahl der richtigen Deployment-Variante kommt es wie so oft in der IT auf das exakte Anwendungsszenarium an. Bei der Definition Ihrer Anwendungsarchitektur und Ihres Solution Designs unterstützen wir Sie gerne.
Literaturverzeichnis
1 Adobe (03.08.2020): Adobe Experience Manager Managed Services | Product Description. Abgerufen am 27.01.2021, von https://helpx.adobe.com/legal/product-descriptions/adobe-experience-manager-managed-services.html
2 Adobe (29.06.2020): An Introduction to Adobe Experience Manager as a Cloud Service. Abgerufen am 27.01.2021, von https://experienceleague.adobe.com/docs/experience-manager-cloud-service/overview/introduction.html?lang=en#value-added-as-a-cloud-service
3 Ihor Dvoretskyi (19.07.2019): Cloud Native Computing Foundation (“CNCF”) Charter. Abgerufen am 29.01.2021, von https://github.com/cncf/foundation/blob/master/charter.md
4 Carlos Santana: Cloud-native principles. Abgerufen am 27.01.2021, von https://www.ibm.com/cloud/architecture/architecture/practices/cloud-native-principles
5 Adobe (09.12.2020): An Introduction to the Architecture of Adobe Experience Manager as a Cloud Service. Abgerufen am 27.01.2021, von https://experienceleague.adobe.com/docs/experience-manager-cloud-service/core-concepts/architecture.html?lang=en
Autor
Kontaktiere uns
Kontakt
Martin Brösamle
Leiter Vertrieb und Marketing
Balanstr. 73, Haus 19 81541 München
E-Mail: info@eggs.de Headquarter: +49 (89) 743456-0